Re: libc5 dependency change proposal
On Mon, 16 Dec 1996, Chris Fearnley wrote:
cjf >>The shlibs file for libc5 contains:
cjf >>
cjf >>libc 5 libc5 (>= 5.4.13-1)
cjf >>libm 5 libc5 (>= 5.4.13-1)
cjf >>libpthreads 1 pthreads1
cjf >>
cjf >>This indicates for all program linked with the libc 5.4.13 that they will
cjf >>not be able to be installed with prior version of 5.4.X!
cjf >
cjf >Yes, this is necessary. Although all software linked against older
cjf >libc5s should run under the newer libc5, any software linked against
cjf >the newer libc5 may not work correctly if libc5 is downgraded. There
cjf >is and must be a ratchet on the gears of libc5 :)
The definition is that there should be general compatibility within a
major version such as libc5 (that is why we have the major number in the
package right?).
When the secondary number is incremented then the interface has been
extended but the old calls are still available.
Within a version like 5.4 the interface is stable.
cjf >I believe the "definition" of minor version number in shared libs is
cjf >that linking against the newer library might break the older library.
No. The intend of the ELF scheme is to guarantee sucess of linking against
a newer library as much as possible. Things are supposed to break around
major versions.
cjf >Although sometimes full backward compatibility may be possible, in
cjf >general it is not possible. So as a matter of policy, each new
cjf >upstream of any library should increment the .shlibs file to x.y.z-1.
No way. This means if the libc maintainer introduces a bug in a recent
release of his libc then I cannot use an old library that works with it
but I am forced to use the buggy library.
--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---
PGP Public Key = FB 9B 31 21 04 1E 3A 33 C7 62 2F C0 CD 81 CA B5
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: