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.
From where do you determine your list of locales?
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.
Hm, I was sort of hoping you had come up with a good way that doesn't require maintaining a list. :)
I can review this.
Offhand: 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 deal). 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: %{_datadir}/locale/ 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 Core)?
Created attachment 136186 [details] list of locales used by kde(-i18n)
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...
> 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. (:
Now that this is moved to Fedora Extras, I'll un-CC notting so he doesn't get any more of this bugzilla spam. (:
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)
I'd rather it go in Core, actually. I just want a way to not have to hand-maintain a list.
> 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)
Bill, are you really gonna take this, or should Robert be the one to submit a new/updated package to review?
I'll get to it... need to go play with repoquery.
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?
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. /usr/share/man/fr/man3 /usr/share/man/hu/man{1,8} /usr/share/man/id/man8 /usr/share/man/it/man3 /usr/share/man/pl/man7 /usr/share/man/pt_BR /usr/share/man/pt_BR/man{1,5} /usr/share/man/ru/man{1,3,5,8} /usr/share/man/ru/man3 /usr/share/man/sk/man8 /usr/share/man/tr/man{1,5,8} /usr/share/man/zh_CN/man{1,8} /usr/share/man/zh_TW/man{1,8}
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. (:
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. :)
So, we can generate this automatically. However, that would involve generating and owning roughly 117k LC_MESSAGES directories.
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.
No, I'm pretty sure we don't need that many. But it would be entertaining, if it didn't break THE FILESYSTEM ITSELF. Hee.
Fixed in filesystem-2.4.0-1 (/usr/share/locale only). We'll see if we can get it in.
Sorry, but the LC_TIME directory is missing (e.g. find /usr/share/locale -name coreutils.mo)
Hm. For something that specific, I'd argue that coreutils should own the directory.
But is this really coreutils specific?
AFAICT, yes.
IMHO the result is broken anyway, when looking into: /usr/share/locale/dar /usr/share/locale/dar/LC_MESSAGES /usr/share/locale/day /usr/share/locale/day/LC_MESSAGES /usr/share/locale/de /usr/share/locale/de/LC_MESSAGES /usr/share/locale/del /usr/share/locale/del/LC_MESSAGES /usr/share/locale/den /usr/share/locale/den/LC_MESSAGES /usr/share/locale/dgr /usr/share/locale/dgr/LC_MESSAGES 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...
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 tools.) az_IR is Azerbaijani as spoken in Iran (translations exist for gtk2). I'm not sure what you expected.
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...