Bug 985981

Summary:	Custom locale location
Product:	[Fedora] Fedora	Reporter:	Eduard Kohler <glandvador>
Component:	glibc	Assignee:	Carlos O'Donell <codonell>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	19	CC:	codonell, fweimer, jakub, law, pfrankli, schwab, spoyarek
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-07-24 18:12:23 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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 :)