Description of problem: tux:~ # rpm -qf /usr/share/locale/*/LC_TIME | wc -l 37 tux:~ # tux:~ # ls -l /usr/share/locale/*/LC_TIME/coreutils.mo | wc -l 37 tux:~ # Version-Release number of selected component (if applicable): coreutils-5.97-11 How reproducible: Everytime, see above. Actual results: /usr/share/locale/*/LC_TIME is not owned by any package, but should owned by coreutils as Bill said in bug #196669 comment #23 and following. coreutils is the only package providing content (a symlink!) for the LC_TIME directory. Expected results: Own /usr/share/locale/*/LC_TIME in coreutils or in filesystem or remove the directory and the coreutils.mo symlinks if possible. Additional info: This bug report is to fix the last bits left open from bug #191581 and #196669.
Shouldn't this be part of %find_lang? coreutils already has this: %find_lang %name ... %files -f %{name}.lang It just sets 'EXTRA_LOCALE_CATEGORIES' in po/Makevars. I think the %find_lang macro should handle this, and cause packages to own directories other than LC_MESSAGES.
Jim had mentioned that this (LC_TIME) is needed for platforms that don't have new enough/correct locale information. Is our locale information in Fedora/RHEL new enough that we don't have to ship LC_TIME symlinks?
Hi Bill, Tim. I've dug some more, and now believe the LC_TIME directories and symlinks are required. The problem is to support ls usage (admittedly twisted) like this: $ env -i LC_TIME=zh_CN LC_MESSAGES=fr_FR /bin/ls --time-=loc -ld / no-such /bin/ls: no-such: Aucun fichier ou répertoire de ce type drwxr-xr-x 27 root root 4096 10-13 09:23 / where LC_TIME is different from LC_MESSAGES: French diagnostics, but date/time using the Chinese format.
Tim, thanks for fixing this bugreport in -13...closing now.
I still think this should be part of %find_lang.