Bug 985981 - Custom locale location
Custom locale location
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Carlos O'Donell
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-07-18 12:33 EDT by Eduard Kohler
Modified: 2016-11-24 11:07 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-07-24 14:12:23 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Eduard Kohler 2013-07-18 12:33:36 EDT
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?

How reproducible:

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)

Actual results:

Log into machine and discover that your nice locale is gone.

Expected results:

Log into machine and enjoy life.

Additional info:

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
Comment 1 Eduard Kohler 2013-07-24 14:12:23 EDT
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 :)

Note You need to log in before you can comment on or make changes to this bug.