Re: libc6 dependency generation
On Fri, Sep 27, 2002 at 11:29:45AM -0400, Daniel Jacobowitz wrote:
> On Fri, Sep 27, 2002 at 11:27:09AM -0400, Brian White wrote:
> > > > What confuses me is why libc6 would make a change like that in a "minor"
> > > > revision (as indicated by the version number of the package). I would
> > > > have expected the glibc guys to only redefine functions during the
> > > > change of the "medium" or "major" revision numbers.
> > >
> > > Minor releases they only require backwards compatibility, not forwards.
> > > "Medium" releases are huge. The "Major" revision is reserved for
> > > something which will require a global change of soname - which they
> > > have no intention of allowing.
> >
> > And that answers my original question. The libc6 "definition" of the
> > "medium" and "minor" revision numbers are different than what I had
> > expected them to mean. Thank you!
> >
> > Out of curiosity, would a "medium" change retain any amout of backward
> > compatibility?
>
> Actually, medium releases also retain _complete_ binary compatibility.
> They're just a little more pronounced.
>
> Glibc has no intention of breaking binary compat without bumping
> soname, and no intention of bumping soname.
Yeah, I think for glibc a "medium" change means core changes in the
underlying system. They always retain backward binary compatibility.
Sometimes a medium rev will break source compatibility though.
As for major version increases, Daniel's right. We'll wont see a libc7
in this century.
And to answer anyone's question about "cruft", see the Debian glibc
package build and it's usage of --enable-kernel, or check the
documentation on the --enable-oldest-abi configure flag aswell.
Ben
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
Reply to: