[gobolinux-users] Re: Compiling Glibc 2.3.6

[Carlo Calica]

On 5/13/06, Sean E. Russell <gobo at ser1.net> wrote:
> On Saturday 13 May 2006 00:17, Carlo Calica wrote:
> > 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.
>
> Am I understanding that there are two, separate, unrelated problems?  One is
> compiling glibc itself, and the other is breakages due to a glibc upgrade?
>
yep.

>
> I can't believe that resorting to a rescue disk is ever a good solution to
> something that is foreseeable and occurs during normal system maintenance.
> The user hasn't done something wrong, or mis-configured something; there's
> been no hardware failure.
>
> I'm not opposed to rescue disks; I just don't think that they should be a
> standard tool for upgrading software.
>

What is normal?  Is the mix'n match normal?  I'll explain managed below.

>
> This sounds pretty reasonable.  Will there be a mechanism in the recipe to
> keep people from accidentally installing glibc the "wrong" way?
>
yes

> > > 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
> ...
> > Wow.  That sounds like an ABI breakage.  Here's the problem:
>
> I don't know; I think it was more along the lines that libxml wasn't a slotted
> package, so the upgrade installed libxml.so.1 and deleted libxml.so.0, which
> everything linked to.  Different, and more easily solvable, problem than an
> ABI issue.
>
That's ABI breakage.  Just Gentoo not using their method for dealing
with it (slots)

> Hm. There's also the toolchain problem with glibc, which we've talked about.
> If the deps tree is already known, and is being *used* to maintain a working
> state, then upgrading glibc shouldn't be a problem -- as long as you can work
> around the toolchain problem.  Is that accurate?
>

Ideally, the system will never be in an inconsistent state.  This
means "make install" needs to be safe.  The new libc should be
isolated until it is actually used.  A static toolchain will complete
the build but that isn't good enough.

<snip Gentoo discussion>

> > I see the situation as a compromise between a "version mix n match"
> > and "managed, QA'd deployment".
>
> By managed, you mean bundled system upgrades?
>

It can mean a lot of different things.  One is Fedora where updates
for each release are separate.  FC1 will never have GCC 4 but it is
the default for FC5 (no idea if true or not).  You start with a base
system and limit updates to compatible changes.  The problem is, if
your one an old release you update potential is limited.  For that
reason it is important to have easy migrations to new releases.

I guess I'm mainly thinking about binary packages.

> > 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".
>
> You probably have more knowledge in this area than I, so excuse me if I don't
> understand why managed and mix-n-match are so different.  I think that the
> impact of ABI breakages can be managed with
>

It has to do with stability (and I'm not talking about your machine
crashing).  Some upgrades require sweeping changes across the system.
Those wouldn't happen in a update, it would wait for a new release.

>
> Yes, some ABI breakages will slip through, either through mistakes by recipe
> writers or by upstream changes which fail to warn about breakages, but I do
> think that the problem can be minimized, and that this would catch most of
> the cases.  Where it fails most grossly is when the BREAKS_ABI flag is in,
> say, version 4.0, and the user is going from 3.5 -> 4.1.  A possible solution
> for this to to include in the recipe a _sparse_ history of every revision
> that breaks the ABI.  Compile could then do a simple check to see if the
> version delta includes one of these breakages.  Users who write manage their
> own recipes will be no worse off, and users who rely entirely on "official"
> recipes wouldn't have to worry about ABI issues.  As much.
>
You said it, "breakages will slip thru".  Most distros try to do it by
managing version ranges in dependencies.  Gentoo is good at managing
it.  The libxml you described sounds like developer error not enabling
the slot.

> This is a lot of work to do, although I think it's much more do-able than
> rewriting Linux's link loader.  I'm aware that I'm being one of those people
> who are doing a lot of demanding, and not significantly contributing, and I
> apologize for that.
>

<grin>  Feedback wanted, demands ignored.


-- 
Carlo J. Calica