[gobolinux-users] Re: Compiling Glibc 2.3.6

[Jonas Karlsson]

2006/5/11, Hisham Muhammad <hisham.hm at gmail.com>:
> 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.
>
How about a "upgrade glibc script" that builds static packages of the
toolchain, then upgrades Glibc and finally builds dynimic packages of
the toolschain againt the new Glibc? This, of course, should not be
recommended for everyday use, but could be useful for some of us.

> Dependencies on newer Glibcs in
> Recipes should actually be considered bugs (I don't know of any
> program that requires very recent Glibc features).
>
KDE 3.5 and later require Glibc 2.3.5 (or 2.3.6, I can't remember).

-- 
/Jonas