Re: Consensus: Locale format may change from release to release?

[Mike Frysinger <vapier at gentoo dot org>]

On 13 Oct 2015 10:03, Carlos O'Donell wrote:
> In general no new processes should be started during the glibc upgrade
> until after all libraries have been replaced as a single atomic unit
> and all dependent data upgraded as  single atomic unit.
> 
> We don't do this in Fedora. There is a race window where the libraries
> are updated one by one (as the writes hit disk), and then the locale
> archive is processed entirely and 100% replaced (along with the C.utf8
> binary locale). During this race window applications may fail to start
> with library dependency issues and locale data format issues. Distributions
> should fix this, but they haven't.

Gentoo does the same and it hasn't generally been an issue as the atomic
renames of all the files in once tends to be "fast enough"

> I suggest we make a "Best Practices for upgrading glibc" document that
> starts like this:
> 
> (1) No new processes should be started during the glibc upgrade
>     until after all libraries have been replaced as a single atomic
>     unit and all dependent data upgraded as single atomic unit.
> 
> (2) Locales should be recompiled for the glibc that is about to run.
>     Any old compiled locales cannot be considered safe to load with
>     the new glibc. There is no guarantee, even between point releases
>     that the binary format remains compatible. This includes recompiling
>     the locale-archive and any other binary locales.
> 
> (3) The project assures that invalid locales will be detected to the best
>     ability of the project, specifically when the project itself changes
>     the binary on-disk format and such old locales which can't be loaded
>     will be ignored or if specifically requested, errors returned, and the
>     fallback locales used.

sounds fine
-mike

Attachment: signature.asc
Description: Digital signature