[gobolinux-users] Re: Compiling Glibc 2.3.6

[Hisham Muhammad]

On 5/11/06, Jonatan Liljedahl <than at home.se> wrote:
> On Thu, 11 May 2006 09:01:17 -0300
> Rafael Guterres Jeffman <rafael at tteng.com.br> wrote:
>
> > Sean E. Russell wrote:
> >
> > >Am I the only one who thinks this is a fairly significant problem?
> > >
> > It is a very significant problem. But upgrading Glibc is a problem in
> > every distribution. On Debian updating it means that you will have to
> > update a lot of packages (often more than with a "distupgrade").
> >
> > Although, updating Glibc is not done often, and could no be done at
> > all. I'm still running 2.3.2 and I'm happy with it. Glibc should only
> > be updated on major changes.
> >
> > I vote that Glibc is only "updatable" when we release a new version
> > of the entire distro, and it should not be available as a Recipe on
> > the "standard store", or as a binary package. Maybe it is time for a
> > "Development Store", and that each new version of GoboLinux comes
> > with a "update distro" option/script.
> >
> > 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.
>
> I upgraded to Glibc 2.3.5 with NPTL (from source) when I wanted support for
> HAL 0.5.4 (and D-Bus 0.50).

Yes, I have also performed successful Glibc upgrades in the past.
Declaring that it's not possible to do it is painting an unfair
picture. The thing is that this is a very delicate upgrade, that's
very susceptible to changes in the Compile scripts, Glibc recipe and
flags, Glibc versions, GCC/Binutils toolchain, kernel version, and so
on, and so on. Of course, the _ideal_ is to keep all of those things
in check at all times to make sure that the combination always works;
we all know that. ChrootCompile goes a long way into allowing safe
testing of those combinations.

The main problem with upgrading Glibc as I see it is the ABI breakage
it invariably causes. Programs compiled with a newer Glibc simply
don't run with older ones. We tend to keep old Glibc versions around
so that when we provide binary packages they're still compatible with
what's running in people's systems. Dependencies on newer Glibcs in
Recipes should actually be considered bugs (I don't know of any
program that requires very recent Glibc features).

-- Hisham