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

[tvali]

On 24/03/06, Paul de Vrieze <pauldv@g.o> wrote:
> 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)).
>
> Calculating after build is only for validating configurations. It allows
> one to see whether one can merge binary package A on the current system

Ok, i'm starting to fully understand it :)

So it is something what could be helpful even on other linux systems
than gentoo?

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

Yes i'm here thinking about my code-deps :)

> 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.

If i can understand you now, then i would think that you didnt
understand me fully. I will write my script, then..

> 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.

I meant headers as .h or .hpp files, which contain function headers.
They're needed, but they are in many cases, included in pack which
uses them, even if that means putting some .h's into all libs.

> 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).

Cant understand it. Do the *headers* change so much through versions?
Is there no backward-compability in so many cases?

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


--
tvali

Measuring programming progress by lines of code is like measuring
aircraft building progress by weight. -Bill Gates

For every complex problem there is an answer that is clear, simple,
and wrong. -H L Mencken

Theory is when you know something, but it doesn't work. Practice is
when something works, but you don't know why. Programmers combine
theory and practice: Nothing works and they don't know why.

http://www.eskimo.com/~hottub/software/programming_quotes.html
http://www.softwarequotes.com/

-- 
gentoo-portage-dev@g.o mailing list