GNU bug report logs - #29537
Core updates broken

Previous Next

Full log

Message #44 received at 29537 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Marius Bakke <mbakke <at> fastmail.com>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, 29537 <at> debbugs.gnu.org
Subject: Re: bug#29537: Core updates broken
Date: Mon, 04 Dec 2017 10:28:36 +0100

Hello!

Marius Bakke <mbakke <at> fastmail.com> skribis:

> Ricardo Wurmus <rekado <at> elephly.net> writes:
>
>> Marius Bakke <mbakke <at> fastmail.com> writes:
>>
>>> Gábor Boskovits <boskovits <at> gmail.com> writes:
>>>
>>>> It seems, that we have a breakage in current core-updates. m4, gettext, and
>>>> at least a few other packages fail to build.
>>>
>>> Hello!
>>>
>>> The problem is that the glibc version string is used a couple of places
>>> to determine where locales are found.
>>>
>>> The attached patch fixes it, though I'm not sure if it's the best
>>> approach.  Thoughts?
>>
>> Thank you.
>>
>> I find it a little ugly to replace the exact version string with only
>> the major+minor version substring.  Why can’t we use the full version
>> string?
>
> I think it's because "glibc-versioned-locpath.patch" uses the libc
> VERSION constant.

Right.  That’s akin to the “effective version” string as defined in
Guile and other packages for cases where you only care about
MAJOR.MINOR.

> Perhaps we could substitute glibcs "version.h", but that might break
> other things.  Or introduce a different variable, say
> GUIX_GLIBC_VERSION, and use that.  WDYT?

FWIW I think your patches does the right thing.  If we want to reduce
ugliness, we can always add an ‘effective-glibc-version’ property in the
glibc package, but that probably won’t be much less ugly than calling
‘version-major+minor’.

Thoughts?

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.