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

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
#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: