[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libc6 dependency generation



> > But that still leaves the question: Why is a change from 2.2.5-4 to
> > 2.2.5-13 changing the symbol set?  I would have expected that the
> > upstream "libc6" group would not do that on minor revision changes
> > (i.e. 2.2.4 to 2.2.5).  Surely there is some upstream libc6 policy
> > they follow that says, for example:
> 
> Please don't guess things like that.

I'm a software programmer of considerable experience (20+ years).  I
believe I have the ability to make educated guesses as to the design of
various software projects.  Taking a few moments to do also means that
I learn better as people explain the way things really are and why they
are that way.  You should never discourage someone from taking initiative
when it comes to learning and thinking on their own; they are essential
skills in programming as well as life in general.

If you see some flaws in the example policy I wrote, please feel free to
point them out.


> Glibc has alot of linker magic
> in it to permit them to fix things.  For example, they may restrict
> the ability of new programs to link to a symbol but still allow old
> programs to call it.  They may introduce some extra functionality in a
> call, but permit older programs to still run correctly.

Just because it can does not mean it should.  I'm not saying "it should
not", and never have.  I don't know enough about it which is why I'm
inquiring.

However, "linker magic in it to permit them to fix things" sounds a lot
like "we can get away with bad decisions because the linker will hide
them".


> Glibc works with a concept of "OLDEST_ABI".  There are functions that
> are available on i386 glibc which are not available on, say, the s390.
> Because the s390 was never around before certain symbols were
> obsoleted, there's no reason to provide them.

That's great from the point of view of "backward compatibility" as the
library evolves.  However, it does not help with "forward compatibility"
when trying to run newer programs with an older library.  Granted, that
is an issue of considerably less importance but one that should still be
considered if the architecture allows.

Perhaps I can boil my original question down to:

Does libc6 have any desire to be "forward compatible" with programs linked
against a version later than the one currently installed?  Such would allow
things like including a single package from a later Debian distribution
without the need to upgrade the base system.

                                          Brian
                                 ( bcwhite@precidia.com )

-------------------------------------------------------------------------------
      Sticks and stones may break bones, but words will shatter the soul.



Reply to: