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

Re: Once again: libc6 packages compatibility etc...



joost witteveen writes:
 > > The libc4 -> libc5 didn't have this bad a transition.
 > 
 > I assume part of this was because the dynamic linker can tell the difference
 > between aout and ELF libraries/binaries, and "knows" which libraries
 > to use for which binaries. This isn't the case with the libc5/6 transition,
 > as with the "statically linked" libraries, there's no way to tell what
 > libc a librarie was compiled against.

$ ldd -v       
ldd: version 1.9.6
$ ldd /lib/libdb-2.0.4.so 
        libc.so.6 => /lib/libc.so.6 (0x40010000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)
$ ldd /lib/libext2fs.so.2
        libc.so.5 => /lib/libc.so.5 (0x4001a000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0x400d6000)

How should I interpret that ?  I don't know whether this is a sure
way of finding out, but at list in some cases, it can show valid
results !


Brian White writes:
 > What I'm wondering is if there is a better way.  One that doesn't cause
 > as many problems as this silly "g" suffix stuff.

About the "silly g-suffix stuff":

* AFAIK, the only packages concerned by this problem are those
containing shared libs. Even in the case where they contain other
stuff (eg. binaries), the shared libs could be taken out into their
own package.

* As already mentionned some monthes ago, in most cases shared-lib
packages are unimportant for the user, ie. they can be (optionally)
hidden from the user, whose concerns are in packages depending on
these libs, and these libs can be automagically handled by
dselect/deity/whatever (don't know whether they finally decided to
allow that, though)

* Then all the "g" stuff can be hidden from the end-user, except if he
really wants to have control over the libraries, in which case he'll
have to know how to distinguish between libc5 and libc6 libs.

But maybe using names like "libfoo3-libc5"/"libfoo3-libc6" instead of
"libfoo3"/"libfoo3g" would be more explicit for those who really care
to manipulate the libs.  It would probably even need no evolution for
whatever libc transition we'll have to do, and I surely prefer it to
switching to "libfoo5h" when libc7 is out ;)


Am I totally out of subject, or does this talk to somebody here ?
-- 
Yann Dirson  <dirson@univ-mlv.fr>        | Stop making M$-Bill richer & richer,
alt-email: <ydirson@a2points.com>        |     support Debian GNU/Linux:
                                         |         more powerful, more stable !
http://www.a2points.com/homepage/3475232 |
		    -----------------------------------------
		    A computer engineer's looking for a job !
		    -----------------------------------------


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: