Red Hat Bugzilla – Bug 857276
glibc-common deletes any local locales on upgrade
Last modified: 2016-08-09 15:28:53 EDT
When locale locales are used, e.g. via:
localedef -i /usr/local/share/i18n/locales/foo_BAR -c -f UTF-8 foo_BAR.UTF-8
and glibc-common is upgrade any such locale locales get deleted.
Subsequently (on reboot) any services which strictly depend on these locales break utterly, e.g. postgresql when it uses such a locale in a database; therefore the high severity.
Please automatically re-generate also the locale locales, like e.g. Debian does since ages.
It's not the first time my /etc/localtime has disappeared after glibc upgrade.
After todays rawhide upgrade to
I've found out this link in /etc
/etc/localtime.rpmnew -> ../usr/share/zoneinfo/US/Eastern
and my original /etc/localtime pointing to Europe/Prague was lost.
Is there any chance there will be upgrade process tested by the package maintainer before it kills rawhide user's machine?
So far the fix for my time issue was simple by adding localtime link by hand...
Zdenek, the problem you're referencing is completely and totally different than the original reporter.
The handling of /etc/localtime is in a state of flux, initially due to packaging changes within glibc itself and more recently due to moving the ownership/management of /etc/localtime to systemd for F18 and beyond.
Red Hat Enteprise Linux 6.9 is in production phase 2, and as such only urgent priority bug fix errata will be considered. Red Hat engineering does not quality this bug as urgent. The behaviour has been present for the entire lifetime of RHEL6, and fixing it would require major restructuring of how locales are tested and deployed.
The solution is not to add the local locales to locale-archive and instead place the compiled locales in /usr/lib/locale which will be searched after the archive. Upstream Fedora is doing this to support C.UTF-8 outside of the locale-archive file.