Re: Slink to potato upgrade
ijr@po.cwru.edu writes:
> On 22-Mar-99 Jules Bean wrote:
> > A libglib which has been compiled under libc2.0 will then segfault any
> > program which is linked to it with libc2.1, if the program calls g_print.
> >
> > Apparently it's something to do with va_args, I haven't looked into it in
> > detail.
> >
>
> This is not broken per se. This behavior is addressed in the FAQ. Libraries
> depend on libio, ie. glib, need to be recompiled with glibc2.1 to be compatible
> with programs compiled with both glibc2.0 and glibc2.1.
>
Frankly, you're all missing the point. We're not libc6 developers here, all
this talk of internal symbols vs exported symbals and whether it's staroffice
and jdk at fauilt or libc6 is *completely irrelevent*. We're packaging a
distribution here not developping libc6, and if upgrading libc6 will break
users' software then something is fubarred in our distribution.
It seems to me that at a bare minimum we need separate package names for libc6
and libc6.1 and be able to have both installed simultaneously even if they
have the same soname. We would also need separate a new suite of altdev
packages to build slink packages and
I also fail to see how it's at all reasonable to have the same soname if the
library isn't downwards compatible. This means that programs compiled on a
potato system will seg fault randomly on a libc6 system because it still has
the same soname dependencies. The fact is that sonames promise both upwards
and downwards compatibility and one without the other is not enough.
Perhaps we need a stub library libc6.1 with a separate soname that libc6
depends on, this will cause potato binaries to depend on libc6.1 as well as
libc6 and they will correctly fail to start with link errors on a slink
system. It will also allow a libc6.1 slink package to be installed without
doing a complete update.
Maybe someone else can explain what this buys us over updating the soname
properly though. Does it provide any level of binary compatibility?
greg
Reply to: