Re: libc5 dependency change proposal
'Christoph Lameter wrote:'
>
>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.
When this happens, downgrading libc5 may break a program that was
compiled with the extended interface, right? Anyway I haven't gotten
any sleep and I'm not sure which of x, y or z in libcx-x.y.z matters
for non-ratchetable downgrades. Certainly if a package is built under
x=5 and we downgrade to x=4, the package built under x=5 can't be
expected to work. This is true with the y value as well. However a
package built under a lower y can be expected to work on upgrades (this
isn't true for x!). How does the z value work? My brain is mush, so
I'll defer to the experts.
--
Christopher J. Fearnley | Linux/Internet Consulting
cjf@netaxs.com, cjf@onit.net | UNIX SIG Leader at PACS
http://www.netaxs.com/~cjf | (Philadelphia Area Computer Society)
ftp://ftp.netaxs.com/people/cjf | Design Science Revolutionary
"Dare to be Naive" -- Bucky Fuller | Explorer in Universe
--
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: