Re: libc6 dependency generation
On Fri, Sep 27, 2002 at 08:36:28AM -0400, Brian White wrote:
> > > It seems to me that changing the ABI with every release of the package is
> > > a bad idea to begin with. After all, there are some systems using
> > > binaries that are _not_ debian packages (with all the exact dependencies)
> > > and it would be nice to have them continue to run even after a upgrade,
> > > espectially one as apparently minor as 2.2.5-4 to 2.2.5-13.
> >
> > When the backware ABI changes, that's usually a good thing, because it
> > means something was fixed.
> >
> > However, that doesn't make old binaries not work. The change is that
> > newly compiled binaries will not work on older libc6. That's why we bump
> > the dep-rev.
>
> I was thinking about that. What kinds of things count as an "ABI change"?
> If it was change to a passed structure (not just a mere extension) or
> something, then the library would not be backward compatible with apps
> built against earlier versions. That leaves, as far as I can see, the
> set of functions/symbols exported by the library. This, as long as
> the library still provided the older symbol set, could remain backward
> compatible.
If foo() takes an int arg, and is versioned @@GLIBC_2.2. Then it
suddenyly takes an off_t arg (which may be different on different
platforms, a new one will be created and versioned @@GLIBC_2.2.5.
Old apps will continue to use foo@@GLIBC_2.2, which is guaranteed to be
compatible. Just remember the whole reason for the versioned symbols.
Now, for further reaching things like LFS, you have to enable that (like
we do now). 99.99% of the time, glibc upstream will not create a change
that breaks old apps. One example of a case where they did was nice()'s
return value changing between 2.2.5 and 2.2.6, but that's only because
the old nice() was just plain broken and wrong.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
Reply to: