Re: [PATCH] ldconfig: set LC_COLLATE to C

[Carlos O'Donell <carlos@redhat.com>]

On 11/27/2017 09:16 AM, Florian Weimer wrote:
> On 11/27/2017 06:15 PM, Carlos O'Donell wrote:
>> On 11/27/2017 09:02 AM, Florian Weimer wrote:
>>> On 11/27/2017 05:36 PM, Carlos O'Donell wrote:
>>>> A quick brainstorm:
>>>>
>>>> * Do nothing. A minimal number of users have broken systems because of collation
>>>>     in their locale breaks certain packages adding known to sort incorrectly entries
>>>>     from their distribution for ld.so.conf.d/.
>>>>
>>>> * Switch to C collation and have an unknown number of users with broken systems
>>>>     because they used locale specific sorting for files they added to the
>>>>     ld.so.conf.d/ directory to configure their systems.
>>>
>>> We can also enumerate twice and warn if there are any differences.
>>
>> Are you suggesting a 2 release staged change?
>>
>> * First release compare both collations, warn on differences.
>>
>> * Change the release default, and stop warning.
>>
>> It would not make sense to keep warning after the change.
> 
> Why do you say that?
> 
> System administrators might see the warning and realize immediately that this is an important change.

Once the change is made to use C/POSIX locale for collation, the warning
becomes a false positive. Why issue a warning at that point? No change is
required by the system administrator.

The warning is important leading up to the change to notify the system
administrator that the system behaviour is about to change in the future
(particularly if they are on a 2.27-based release and will pickup this
change soon e.g. Fedora Rawhide).

>>> Or provide a tool like (glibc-system-check?) which reports this and
>>> could be extended over time to also check for use of deprecated
>>> features/APIs and so on.
>>
>> Would we use the tool to block upgrades?
>>
>> Detect /etc/ld.so.conf.d/* file names that would sort differently
>> given the current locale and C locale, and return non-zero with
>> a warning?
> 
> No, I think it would have to be purely advisory.

OK.

Given my comments above, do you recommend a 2 release change process?

* Deprecate with warnings.

* Change default, and remove warning.

-- 
Cheers,
Carlos.