[bug#30873] [PATCH core-updates 1/3] gnu: glibc: Update to 2.27.

[Marius Bakke]

Ludovic Courtès <address@hidden> writes:

> Hello!
>
> Thanks for working on this update!  Crazy that it turned out to be this
> difficult.
>
> Marius Bakke <address@hidden> skribis:
>
>> +++ b/gnu/packages/patches/glibc-2.27-git-fixes.patch
>> @@ -0,0 +1,12765 @@
>> +This patch includes all post-release fixes for version 2.27 up to commit
>> +3b922526415d1af93fe5a0e3caf7e6a790cb1619.
>> +
>> +https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/release/2.27/master
>> +
>> +Generated by "git diff glibc-2.27..release/2.27/master".
>
> In general I’d be in favor of not doing that, unless the fixes are
> important (build issue, security issue, etc.), as was the case when we
> packaged 2.26; and, if there are important fixes, I’d rather extract
> them from the whole patch stream, and skip unrelated changes.
>
> For example, I’m sure we can live without the locale updates that show
> up in this patch set.  :-)
>
> Do you know which of these patches are really needed?
>
> Thoughts?

Hello!

I was hoping you'd comment on this ;-)

There are actually not a lot of high severity fixes in 2.27 yet.  I
opted for this mostly as a proof-of-concept for a couple of reasons.

* Giving the GNU C Library special treatment is OK IMO.
* In 2.26, cherry-picking individual fixes was not feasible.
** However, using the same method, the 2.26 diff is "only" 27k lines/904k.

It does mean growing the Guix repository up to ~1MiB every six months,
but in the large scale of things, it doesn't seem that bad.

Yet, I'm not sure if it makes sense to do this now.  There are only a
handful of "important" commits on 2.27 so far.  Additionally, the 2.27
release manager has said he would do 2.27.1 once (if?) enough patches
has piled up, so maybe there is hope for the future.

The question is which do we pick?  Portability fixes for arches we don't
(yet) support?  Some of the locale fixes seem genuine, and not just
typos, e.g.:

* https://sourceware.org/bugzilla/show_bug.cgi?id=22517
* https://sourceware.org/bugzilla/show_bug.cgi?id=22848

Actually, now that I've scoured the history, reverting this one commit
brings the patch from 12921 to 2391 lines:
<https://sourceware.org/git/?p=glibc.git;a=commit;h=b63daad97ec1a9adccf028cfdebedff2b3660097>.

~2k isn't too bad IMO.  Yet, I've attached a patch with only the
following commits, and without NEWS and ChangeLog updates.  It's 547
lines, which is more palatable; but may grow longer than the unified
approach since it includes git commit logs.

56170e064e2b21ce204f0817733e92f1730541ea
516fa6080481a1433c173320b1c1432868e1e38a
f36553bf6a4f69070f99badbdab5802b43e6e211
7c6304182b9f422b782ace1cdd3efbde056aec36
78a90c2f74a2012dd3eff302189e47ff6779a757
1e52d8e65a58c49a48549053a1b89c06240e0c6c

But, we risk missing important commits this way, and may cause headaches
for people wanting to port Guix to a new architecture.  And the approach
doesn't really scale for branches approaching ~100 commits.

Regardless, here is a patch with just the above commits.  Let me know if
you spot others in the history that look important.  WDYT?

I suppose we'll have to revisit this with every 'core-updates'.  :-)

0001-gnu-glibc-Update-to-2.27.patch
Description: Text Data

signature.asc
Description: PGP signature