guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Gracefully handle incompatible locale data


From: Ludovic Courtès
Subject: Re: [PATCH] Gracefully handle incompatible locale data
Date: Sat, 26 Sep 2015 12:24:56 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

"Carlos O'Donell" <address@hidden> skribis:

> Despite Roland saying "LGTM", I think this is not a good change.
>
> Firstly, it's not the community consensus as Ondrej is pointing out.
>
> https://sourceware.org/glibc/wiki/Style_and_Conventions#Error_Handling

“Assertions are for internal consistency checking only.”  I would argue
that what this patch changes is not an internal consistency check.

Furthermore, the function in question returns EINVAL in other similar
cases–e.g., when libc 2.22 loads LC_COLLATE data from libc 2.21.

So it is not clear to me that the patch would be a violation of these
rules.  WDYT?

> It is a fundamental system misconfiguration issue not to have upgraded
> the binary locale data from one release to another.

I would not call it “misconfiguration.”  With GNU Guix, unprivileged
users can install packages in their “profile” and they are free to
choose whether and when to upgrade those packages.  Consequently, they
might be using a libc version different from the one the system
administrator used to build the system-wide locale data.

Currently, the assertion failure greatly penalizes this use case:

  https://lists.gnu.org/archive/html/guix-devel/2015-09/msg00717.html

Returning EINVAL instead of aborting would make things easier.

But it’s not perfect.  IMO, a discussion on improving the coexistence of
different libc/locale versions on the same system is in order.  But it’s
beyond the scope of this two-line patch.

Thanks,
Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]