Re: [gentoo-portage-dev] DB and binary dependency

[Paul de Vrieze]

On Thursday 23 March 2006 21:35, tvali wrote:
>
> BINSLOT is a new word for me.

Ok BINSLOT is normally slot. However in some cases packages are in the 
same slot, but not binary compatible (like their libraries having a 
different SONAME e.g. openssl-0.9.6 and 0.9.7 (iirc)).

>
> I dont see any meaning in calculating dependencies after build. There
> would be too much problems:
> * If any of packages you depend on, are masked, you get an error after
> build, but should get it before

Calculating after build is only for validating configurations. It allows 
one to see whether one can merge binary package A on the current system 
(this might not be the case even if the build dependencies allow it). It 
further allows one to do proper cleaning of obsolete packages. One could 
even use it to find that if say X is updated, all dependent packages 
should be updated too.

> * In many cases, not only libs, but also headers are included from
> another pack [kernel headers, for example, as i have seen from error
> messages]

Header files come from packages that should be mentioned in the 
dependencies.

> * You cant pre-calculate dependancies

Calculating dependencies automatically is diabolically hard. The fact that 
we have a tree that largely works shows that predicting them works well. 
The reason is that the dependencies are statically defined by the source 
of the package. At those parts where people make mistakes, or the build 
systems are broken, occur the dependencies could be verified by automatic 
tools that check most dependencies. Doing that for native code is easiest 
done by disecting the libraries and executables. For header files, 
inclusion parsing is probably a good approach. But then look at what is 
installed, not what was started with. The reason being that at what is 
installed is no longer dynamic based on a configure script, but totally 
static. The only disadvantage being that this only checks the current 
combination of useflags+context. Many checks by many users would however 
give a good test coverage.

> In cases, where both headers and libs are included from other pack,
> which is same on both cases, this is totally irrelevant for deps if
> this other pack is statically or dynamically used.

Not really, with a static library A and a static library B that uses the 
static A, this dependency is only runtime when the interface of B exposes 
the headers of A. If not, one could unmerge both the static library and 
the headers and one could still compile against the library.

> In cases, where headers are in pack to be compiled and .so is in
> another package, i havent yet checked, how to understand if dependancy
> is binary -- i cant say for sure that this does not include some work
> from user.

Ok, let me clarify. With a binary dependency I mean the actual 
requirements of a package once it has been compiled. In general one could 
say that given a depend atom "sys-libs/db-4.*" could be statisfied by 
ebuilds in 5 slots: db-4.{0,1,2,3,4}. The sourcecode does not care which 
one is used. However, code compiled agaist db-4.0.14 will not run against 
any libdb-4.{1,2,3,4}.*. This is because these should libraries live in 
different BINSLOT's (in other words, they are incompatible). As these 
libraries have different SLOT's they can coexist though. For a binary 
package therefore it is necessary to record the version of db it was 
actually compiled against. As this might be very strict I also want to 
say that any package within the same BINSLOT with a higher version than 
the one compiled against also works (as it does).

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@g.o
Homepage: http://www.devrieze.net