Bug 196669 - Review Request: filesystem-i18n
Summary: Review Request: filesystem-i18n
Alias: None
Product: Fedora
Classification: Fedora
Component: filesystem   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2006-06-26 12:11 UTC by Robert Scheck
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version: 2.4.0-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-12 20:19:10 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
list of locales used by kde(-i18n) (896 bytes, text/plain)
2006-09-13 17:52 UTC, Rex Dieter
no flags Details

Description Robert Scheck 2006-06-26 12:11:35 UTC
Spec URL: http://labs.linuxnetz.de/bugzilla/filesystem-i18n.spec
SRPM URL: http://labs.linuxnetz.de/bugzilla/filesystem-i18n-2.3.7-1.src.rpm
Description: The filesystem-i18n package contains the basic i18n directory 
layout for a Linux operating system.

There are some rpmlint errors and warnings but IMHO they can't be avoided:
W: filesystem-i18n no-url-tag
W: filesystem-i18n no-documentation
E: filesystem-i18n incorrect-locale-subdir /usr/share/locale/nso/LC_TIME
E: filesystem-i18n incorrect-locale-subdir /usr/share/locale/lug/LC_MESSAGES
E: filesystem-i18n incorrect-locale-el /usr/share/locale/gr/LC_MESSAGES

This package would resolve bug #191581, an alternative could be to merge its content into the existing filesystem package.

Comment 1 Bill Nottingham 2006-06-29 04:43:30 UTC
From where do you determine your list of locales?

Comment 2 Robert Scheck 2006-06-29 07:53:43 UTC
I wasn't able to find any official locales list, so I simply took what is in
my /usr/share/locale. Beside from this, I'm not sure wether an official locales 
list would contain things like en@boldquot, en_CA or zh_CN.GB2312.

Comment 3 Bill Nottingham 2006-06-29 16:53:42 UTC
Hm, I was sort of hoping you had come up with a good way that doesn't require
maintaining a list. :)

Comment 4 Rex Dieter 2006-09-13 17:18:13 UTC
I can review this.

Comment 5 Rex Dieter 2006-09-13 17:28:08 UTC

1. Any particular reason you used
Version: 2.3.7
or did you just borrow/inherit that from the main filesystem pkg?

Otherwise, I'd suggest simply starting at
Version: 1.0.0
for now.  

2.  You/we should decide upfront (ie, now) what exactly constitute major, minor,
micro Version upgrades.  Thoughts?  (well, maybe it's not really that big of a

3.  %{_datadir}/locale is (still) unowned (ok, glibc-common owns it, but it
should be owned here (too).  You could greatly simplify the %files list by
simply including:

4.  kde uses a similar locale-like heirarchy under %{_docdir}/HTML.  Would be
nice to include that here too.

Bill, this is (very) likely unable to make fc6.  If that is the case, what do
you think about getting this into Extras instead (at least until it can go into

Comment 6 Rex Dieter 2006-09-13 17:52:14 UTC
Created attachment 136186 [details]
list of locales used by kde(-i18n)

Comment 7 Robert Scheck 2006-09-13 17:53:38 UTC
1.: Just copied from main filesystem pkg, but 1.0.0 also would fit.
2.: Well...are there really major, minor or micro version upgrades? Adding a
    new language could be used for bumping micro, bumping minor only for bigger  
    changes, e.g. adding new tree or maybe with every Fedora release, e.g. 1.6.x 
    would be FC6. I wouldn't abuse major version for Fedora release, but maybe 
    also another thought, e.g. 6.x.y for FC6.
3.: Agree, +1
4.: No, please don't do that. Not everybody installing the filesystem-i18n 
    package is interested having a empty KDE directory i18n tree, when KDE isn't 
    installed; which is case especially on servers.
    But if I have to accept that KDE i18n will get part of filesystem-i18n, then 
    the i18n directories from %{_mandir} have to be added, too.

When candidate for FE and until it receives FC, I would like to maintain it in 
FE - if possible...

Comment 8 Rex Dieter 2006-09-13 18:07:05 UTC
> I would like to maintain it in  FE - if possible...

Sure, can do... I'll re-assign this to Fedora Extras then.  (:

4. Re: KDE bits

> Not everybody installing the filesystem-i18n package is interested having a 
> empty KDE directory i18n tree

I don't think I buy that, the same argument can be made for the (mostly empty)
%{_datadir}/locale/* bits.  Besides, what (real) harm is there?  

> the i18n directories from %{_mandir} have to be added too.

Not necessarily.  afaict, most of those are owned by 'man' already.  Though, I
can see the case for including them here too.  OK, I (think) I'm sold, include
those too.  (:

Comment 9 Rex Dieter 2006-09-13 18:08:07 UTC
Now that this is moved to Fedora Extras, I'll un-CC notting so he doesn't get
any more of this bugzilla spam. (:

Comment 10 Rex Dieter 2006-09-13 18:22:39 UTC
3.  Scratch original suggestion, forgot that these items should be marked using
%lang, so we should do something like this instead:
%dir %{_datadir}/locale/
%lang(foo) %{_datadir}/locale/foo/
%lang(bar) %{_datadir}/locale/bar/
(or using a scripted approach similar to to your original proposal)

Comment 11 Bill Nottingham 2006-09-14 21:09:41 UTC
I'd rather it go in Core, actually. I just want a way to not have to
hand-maintain a list.

Comment 12 Rex Dieter 2006-09-15 17:18:18 UTC
> I'd rather it go in Core, actually

who to maintain it then?  you? (;

> I just want a way to not have to hand-maintain a list.

No solution yet... *unless* we want to make a Fedora (packagining?) policy
stating something like:  
This list of locale's are officially supported by Fedora
packages MUST not include locale-specific bits from locale's not included in
this list.

And then you maintain the "official" locale list. (: (to be updated from
time-time, of course, but hopefully, it should stay relatively constant)

Comment 13 Rex Dieter 2006-09-21 20:14:43 UTC
Bill, are you really gonna take this, or should Robert be the one to submit a
new/updated package to review?

Comment 14 Bill Nottingham 2006-09-21 20:16:50 UTC
I'll get to it... need to go play with repoquery.

Comment 15 Robert Scheck 2006-09-23 16:06:38 UTC
Any chance to get this into Fedora Core 6 or will it definately be a canditate 
for Fedora Extras 6 and reach Fedora Core >= 7?

Comment 16 Robert Scheck 2006-09-23 17:16:39 UTC
Rex, regarding comment #8 - the following directories are unowned when looking 
around on a normal Fedora installation at my system, which is a very good reason 
to carry all man directories with filesystem-i18n, too. Guess the exactly number 
of directories depends on the locale selected during setup.


Comment 17 Rex Dieter 2006-09-24 02:56:47 UTC
man already owns most/all of %_datadir/man/<locale>, so  man could also own
%{_datadir}/man/<locale>/man{1-9}.  It could be argued that these should be in
man, and not here, so that manpages will (implicitly) depend on man (for
directory ownership).

OTOH, why should man have to complicate it's packaging so, when it could be so
easily included here?

OK, I'm officially undecided. (:

Comment 18 Rex Dieter 2006-09-25 11:55:27 UTC
Re: comment #15
> Any chance to get this into Fedora Core 6

I was under the impression this was what Bill had in mind, but I won't put words
in his mouth. :)

Comment 19 Bill Nottingham 2006-10-10 20:29:26 UTC
So, we can generate this automatically. However, that would involve generating
and owning roughly 117k LC_MESSAGES directories.

Comment 20 Rex Dieter 2006-10-10 20:39:34 UTC
Wow, that's a lot of locale's... you sure we really want/need that many?  You
could consider pruning the list of locale's to some "officially" supported subset.

Comment 21 Bill Nottingham 2006-10-10 21:10:10 UTC
No, I'm pretty sure we don't need that many. But it would be entertaining, if it


Comment 22 Bill Nottingham 2006-10-10 22:06:11 UTC
Fixed in filesystem-2.4.0-1 (/usr/share/locale only).

We'll see if we can get it in.

Comment 23 Robert Scheck 2006-10-11 07:29:45 UTC
Sorry, but the LC_TIME directory is missing (e.g. find /usr/share/locale -name 

Comment 24 Bill Nottingham 2006-10-11 16:03:04 UTC
Hm. For something that specific, I'd argue that coreutils should own the directory.

Comment 25 Robert Scheck 2006-10-11 16:04:25 UTC
But is this really coreutils specific?

Comment 26 Bill Nottingham 2006-10-11 16:08:39 UTC
AFAICT, yes.

Comment 27 Robert Scheck 2006-10-11 21:02:38 UTC
IMHO the result is broken anyway, when looking into:


Why the hell do we have three character locales now? And where are things like 
de_AT, de_DE, et_EE, eu_ES, bn_IN, az_IR etc.? The current filesystem is 
definetly NOT what I expected when opening this bug report - I'm sorry to say 
this. Hopefully the current filesystem package does not reach Fedora Core 6...

Comment 28 Bill Nottingham 2006-10-12 01:11:59 UTC
dar is Dargwa, day is Dayak, del is Delaware (Indian, presumably), dgr is Dogrib.
They're all valid.

de_AT is German as spoken in Austria (translations exist for texinfo,
gnomebaker, and gdeskcal)

eu_ES is Basque as spoken in Spain (translations exist for a variety of system

az_IR is Azerbaijani as spoken in Iran (translations exist for gtk2).

I'm not sure what you expected. 

Comment 29 Robert Scheck 2006-10-12 20:19:10 UTC
I'm very very sorry. Rawhide build of filesystem is what I expected, but my 
local (mock) build of filesystem is the opposite - just everything I claimed
in comment #27. No matter what went wrong, but this is another thing.

Bill and Rex, thank you very much for doing the job and adding the directories 
to filesystem package :)

Finally I'm pointing to rpm >= 4.4.6, which helped me to figger out this issue. 
For me this bug report was just another (daily) example why Fedora Core should 
be definitely upgraded to a current rpm release. But looks like Jesse and Seth 
etc. are not interested in such enhancements, otherwise they and others would 
have tested it and they wouldn't argue against such really useful things...

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