[gobolinux-users] Re: Compiling Glibc 2.3.6

[Carlo Calica]

First off, I'd like to say any failure to build/install Glibc from
recipes/packages is a problem.  ChrootCompile looks to be the best
solution.

The larger issue is after a successful build/install of glibc (or any
lib) other programs fail due to ABI changes in the upgraded lib.  I'd
like to focus the thread on this topic.

On 5/12/06, Sean E. Russell <gobo at ser1.net> wrote:
>
> Ok.  I'm an end-user, and my opinion is that, no matter what, I don't want to
> upgrade something and have it make my computer entirely unusable, forcing me
> to go to some other computer, download and burn a rescue disk, and spend an
> afternoon trying to get my computer running again.
>

Good baseline :-).  Now how to accomplish it in an imperfect world.
In fairness, a rescue disk isn't too extreme.  The install media
should qualify.

> My *preferred* solution, as I've mentioned elsewhere, is some sort of magical
> mechanism by which I can have numerous versions of glibc and be (mostly)
> ignorant about what links to which version.

Not asking for much :-).

>  As a bonus, I'd like a "who
> uses" script that tells me that -- yes, there are still packages linking into
> glibc-X.Y, so I *can't* uninstall it without upgrading or breaking them.
>
> Actually, that "who uses" script would be a good first step to protecting
> users from the glibc madness.  Put a call to it in the glibc recipe.  Then
> provide another script that does a sandboxed build to upgrade the toolchain,
> link it all in at once.
>
ChrootCompile should provide a sandboxed build.  Then it is a package
install which "should" be easy.  A "who uses" script is easy.
Something like "fgrep $package /P/*/*/R/Dependencies".  Then scan
those package through ldd to narrowdown the version.


> I can see a broader use for this.  Gentoo recently had a lot of problems with
> a libxml upgrade, which broke -- well, almost everything, but especially KDE.
> Because they lack a "who uses" script, and because KDE in Gentoo is broken up
> into a hundred ebuilds, the only recommended solution was a deep rebuild of
> your entire system.
>
> That sucked.
>

Wow.  That sounds like an ABI breakage.  Here's the problem:

Foo > depends > Bar > depends > Baz.

Baz changes ABI.  So Bar gets rebuilt.  Does Bar's ABI change?  The
closer to the root of the dep tree to more things need to be rebuilt.
For glibc it is the root.  I'm not sure how a "who_uses" would help.
The deps tree is already known.

> > > The only reason I see for "forcing an update" is when a serious security
> > > flaw is found on Glibc, otherwise, all one gets is marginal benefits for
> > > too much trouble.
> >
> > Which keeps the upgrade choice in the distro-devs hands.  The end-user
> > will also know which updates are critical and which aren't worth the
> > risk.
>
> Will they?  I've got some 693 packages installed on my Gentoo laptop, and I
> certainly don't keep track of most of them.  I was completely sidelined by
> the libxml issue, and was only saved from a glibc disaster by the pitiful
> cries of others who, too eagerly, ate from the forbidden fruit.
>

Why did you upgrade libxml?  Was it a critical fix or "oh, new libxml,
gotta get it".  I'd argue Gentoo is a bleeding edge distro (at least
how most users use it) which is prone to those issues.


> I think you're being optimistic about users being able to track the status,
> and significance, of upgrades for that many packages.  Furthermore, I'd argue
> that they shouldn't have to pay that much attention to it.  For many people,
> an OS is a tool, not a career or even a hobby.  Many of us don't want to
> spend hours each week trying to keep our OS running.
>

Agree completely.

> For the record, I *do* spend a lot of time dicking with my laptop, tweaking
> it, breaking it, and installing stuff.  But I have three other Linux boxes in
> the house, and those, I just want to be able to upgrade occasionally without
> a lot of pain or effort.  This aggravates the situation, because I do the
> upgrades rarely, so they're usually large, involving a lot of packages, and I
> don't do them all at once, so the nature of the upgrades changes for every
> system.
>

I see the situation as a compromise between a "version mix n match"
and "managed, QA'd deployment".

For a version mix'n match, Compile works well now.  It is impossible
to have ABI stability so don't try.  Dangerous recipes should be
labeled "expert_only".

That leaves "managed".  How should we handle that?

-- 
Carlo J. Calica