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, email@example.com
#what's this? see http://www.dcs.ex.ac.uk/~aba/rsa/
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to firstname.lastname@example.org .