Bug 985981 - Custom locale location
Summary: Custom locale location
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Carlos O'Donell
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-18 16:33 UTC by Eduard Kohler
Modified: 2016-11-24 16:07 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-07-24 18:12:23 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Eduard Kohler 2013-07-18 16:33:36 UTC
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:
Always

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 18:12:23 UTC
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.