Red Hat Bugzilla – Bug 985981
Custom locale location
Last modified: 2016-11-24 11:07:51 EST
Description of problem:
I created a new locale because ... I can. Well mainly because on my English speaking installation having days/month in an other language is ... boring.
Every time some packages get updated (I suspect those who update the locale cache) my nice locale is lost. Where should I put this file to be build into the cache without my intervention?
Can we have a /etc/locale.d/ folder where drop this kind of file and localedef also looks into it?
Steps to Reproduce:
1. Create a nice locale: en_GV
2. Place it inside the /usr/share/i18n/locales/ folder.
3. Compile it: localedef -f UTF-8 -i en_GV en_GV.UTF-8
4. Modify /etc/locale.conf to use the new locale en_GV.UTF-8
5. Log into the machine, enjoy life
6. yum update random package (maybe glibc, but others too)
Log into machine and discover that your nice locale is gone.
Log into machine and enjoy life.
I don't remember the exact complaint from bash, but I don't think it is important.
If I redo the points 2 and 3 and log back into the system, bash is happy
Replying to myself.
The solution is to use the --no-archive flag when compiling the custom locale.
1. Create a nice locale: en_GV. Store it wherever you want.
2. Compile it: localedef -f UTF-8 -i path/to/en_GV --no-archive en_GV.UTF-8
This will create a folder containing the compiled locale, beside the locales archive.
3. Modify /etc/locale.conf or use localectl set-locale LANG=en_GV.UTF-8
'locale -a' command will show you the new locale.
A 'yum reinstall glibc-common' will regenerate the locales archive without touching the new locale folder.
I still don't understand why dropping the custom locale source inside the folder usr/share/i18n/locales/ is not enough to get it rebuild, but I suppose it is buried somewhere inside the spec file.
I'll close this because it is not a real bug, but more a documentation misunderstand.
Thanks for the audience :)