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

Re: Slink to potato upgrade



>>>>> On 22 Mar 1999 13:20:07 -0500, Greg Stark <gsstark@mit.edu> said:

 Greg> 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.
 >>

 Greg> Frankly, you're all missing the point. We're not libc6
 Greg> developers here, all this talk of internal symbols vs exported
 Greg> symbals and whether it's staroffice and jdk at fauilt or libc6
 Greg> is *completely irrelevent*. We're packaging a distribution here
 Greg> not developping libc6, and if upgrading libc6 will break users'
 Greg> software then something is fubarred in our distribution.

This is why it's called unstable.  Don't use it if it causes you
problems.  We are allowed to break thing in unstable.  Everything will 
work again when potato becomes stable.

 Greg> It seems to me that at a bare minimum we need separate package
 Greg> names for libc6 and libc6.1 and be able to have both installed
 Greg> simultaneously even if they have the same soname. We would also
 Greg> need separate a new suite of altdev packages to build slink
 Greg> packages and

 Greg> I also fail to see how it's at all reasonable to have the same
 Greg> soname if the library isn't downwards compatible. This means
 Greg> that programs compiled on a potato system will seg fault
 Greg> randomly on a libc6 system because it still has the same soname
 Greg> dependencies. The fact is that sonames promise both upwards and
 Greg> downwards compatibility and one without the other is not
 Greg> enough.

The fact is they don't.  I've never understood them to promise that.
Major soname the same means that packages compiled with the smaller
minor will work on the larger minor not the other way around.  patch
level promises binary compatibility upwards and downwards.

 Greg> Perhaps we need a stub library libc6.1 with a separate soname
 Greg> that libc6 depends on, this will cause potato binaries to
 Greg> depend on libc6.1 as well as libc6 and they will correctly fail
 Greg> to start with link errors on a slink system. It will also allow
 Greg> a libc6.1 slink package to be installed without doing a
 Greg> complete update.

 Greg> Maybe someone else can explain what this buys us over updating
 Greg> the soname properly though. Does it provide any level of binary
 Greg> compatibility?

It buys us not having to compile every package again to get rid of the 
older glibc.  It buys us a smaller memory footprint because you don't
have to have two copies of every dynamic lib in memory.

Dres
-- 
@James LewisMoss <dres@ioa.com>         |  Blessed Be!
@    http://www.ioa.com/~dres           |  Linux is kewl!
@"Argue for your limitations and sure enough, they're yours." Bach


Reply to: