Re: Slink to potato upgrade
Greg Stark wrote:
>Frankly, you're all missing the point.
It just seems that way because of the forest/trees myopia you are
demonstrating.
>We're not libc6 developers here
Exactly. Therefore, we don't change sonames.
>all this talk of internal symbols vs exported symbals and whether it's
>staroffice and jdk at fauilt or libc6 is *completely irrelevent*.
Not when you're trying to fix it it isn't.
>if upgrading libc6 will break users' software then something is fubarred
>in our distribution.
I believe that assumption is the fatal flaw in your argument. We package
upstream bugs along with upstream software - it's a fact of life. There are
currently 7030 bugs in Debian (not a typo - we're 2970 short of 10k). This
ghastly amount of breakage lets developers like us look at the big picture
and choose the best solution for each problem and try to find which
solutions will cause the least problems further down the road.
JDK? StarOffice? Let them break. The people responsible will have to fix
their software anyway - *all* the distributions will be glibc 2.1-based
soon.
Change the soname? BAH. Doing so would make a clean break, sure, but it
would give up the promise that the glibc 2.1 upstream authors are delivering
on - upgrades without soname changes. You simply must understand the amount
of work they've pumped into this. They aren't going to give up on it and
neither should we.
It would also create binary incompatibility with every other Linux
distribution. The technically competent would mock us (they've already
mocked you) for fragmenting the Linux community. Debian would stand out as
an incompatible distribution (and rightly so!) whose users generate apps
that noone else can use.
It'd be a total mess, magnitudes worse than the tangible StarOffice/JDK mess
you see now. It's a mess that the developers involved don't ever want to
visualize, so they don't provide details, they just make trite comments like
"You should be kicked in the head for even suggesting such a thing" in the
vague hope that you will just go away and STOP ASKING THEM.
>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
Was that supposed to be the end of that sentence? :)
Glibc 2.1 was designed from the get-go to be backwards-compatible with Glibc
2.0. Much of its internal workings were changed, but the API was extended
seamlessly, thanks to the wonders of symbol versioning.
This works - for apps that don't use libc-internal symbols that don't exist
anymore or have changed meanings. Apps that do are naughty. :)
Furthermore, those problem applications will most likely *not* compile
against glibc2.1 until they are fixed (and would then work on glibc 2.1
if recompiled against glibc 2.0).
Recompiles DO NOT fix these apps.
>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.
Read section 12 of the Debian packaging manual - it has a good overview of
how the dpkg shlibs mechanism works.
>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.
Dependancies already solve this issue - read the aforementioned manual.
>It will also allow a libc6.1 slink package to be installed without
>doing a complete update.
There are no libc6.1 slink packages.
>Maybe someone else can explain what this buys us over updating the soname
>properly though. Does it provide any level of binary compatibility?
Yes - complete backwards compatibility for apps that were written correctly.
"properly" is an incorrect adverb. It would mean that the upstream
maintainers of glibc 2.1, as well as all of the Debian developers involved
with making glibc 2.1 work for everyone, are wrong. I doubt that.
--
Robert Woodcock - rcw@debian.org
"I never knew manipulating the masses was so easy." -jt
Reply to: