Re: Once again: libc6 packages compatibility etc...
> > > The more this goes on, the more I think the best thing to do would have
> > > been to just clean out hamm completely and only let libc6 packages
> > > be uploaded.
> > >
> > > We could still do this, I suppose with very little impact on hamm.
> > > The big problem is with upgrades from earlier versions.
> >
> > But we want to support people using old libc5-based programs (think
> > about those using commercial software), so libc5-based libs are still
> > needed. The way we are doing it now with both libc5- and libc6-based
> > libs coexisting in the same system looks like the Right Thing to me.
>
> That's why it's a problem with upgrades.
>
> 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.
>
> 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.
Other part is probably that we do much better now: I don't think
creation of aout X apps was possible during the libc4/5 transition,
now we can create libc5 X apps. So, I'd say the libc4/5 transition
was much worse than the libc5/6 one.
--
joost witteveen, joostje@debian.org
#!/usr/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
#what's this? see http://www.dcs.ex.ac.uk/~aba/rsa/
--
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: