On Fri, Dec 06, 2024 at 10:43:34AM +0800, Sean Whitton wrote:
> On Thu 05 Dec 2024 at 10:13am -08, Josh Triplett wrote:
> > Package: debian-policy
> > Version: 4.7.0.1
> > Severity: wishlist
> > Tags: patch
> > X-Debbugs-Cc: j...@joshtriplett.org
> >
> > Packages already tend to avoid requiring any files from /usr/share/man
> > or /usr/share/info, and don't require files in /usr/share/locale if
> > running in a C or C.UTF-8 locale.
> >
> > The attached patch documents this in Policy, so that it's explicitly
> > supported for sysadmins to use dpkg exclusions or similar mechanisms to
> > delete /usr/share/doc, /usr/share/info, and /usr/share/locale.
> >
> > To the best of my knowledge, this documents existing behavior, and will
> > not introduce any new bugs on any packages.
>
> We already have the requirement that packages don't depend on
> /usr/share/doc existing, indeed. It certainly makes sense to extend
> this to forms of documentation installed outside of /usr/share/doc.
>
> /usr/share/locale sounds like a valuable, but trickier change. Locales
> are more entangled with their software than is documentation.
>
> In either case, we wouldn't want to make very many packages buggy with
> this change. Do you have any ideas for determining which packages
> currently break if the local admin nukes these directory hierarchies?
Anecdata aside, one other way to evaluate this is to look at the type of
files packages store under /usr/share/locale.
A look at the Contents file gives a complete list of what types of files
packages store there, which in turn indicates how they're used:
- `.mo` and `.po` files, used for translations via gettext. Since these
are read by gettext, it seems sufficient to verify a couple of
examples of gettext behaving as expected with /usr/share/locale
missing (as long as the locale is set to C.UTF-8). I can confirm that
gettext applications seem to have reasonable behavior here.
- `.qm` files, used for translations of qt applications. Applications
deal with these being missing; some such applications already have
separate -l10n packages that they have Recommends on rather than
Depends. So, these are fine.
- `.js`, `.pmap`, and `.pmapc` files in `LC_SCRIPTS` directories, used
solely by a few KDE packages such as kgeography-data. I verified that
kgeography behaves fine with all these files missing.
- `.desktop` files, used only by libkf5configwidgets-data and
libkf6configwidgets-data. As far as I can tell, these solely exist to
give the names of every locale *in* every locale (e.g.
en_US/kf6_entry.desktop has "Name=US English" and
"Name[es]=Inglés de EE. UU.". As far as I can tell, KDE applications
seem to work fine without these files installed, and they just affect
the ability of the language chooser to show language names, which
seems entirely expected.
- A few odd stray/generic files:
- blender-data installs the generically named
/usr/share/locale/languages; I've reported that filename as a bug.
In any case, I've confirmed that blender launches and runs fine
without any files in /usr/share/locale/ ; it displays an empty
language selection list, but works fine with no errors.
- nut-monitor installs /usr/share/locale/NUT-Monitor.pot . If I
understand correctly, I *think* it's a mistake for a package to
install a .pot file. (It also installs .mo files as normal.)
- The game unknown-horizons installs the generically named
/usr/share/locale/stats.json , which as far as I can tell is just a
list of languages with translation percentages. I can't test whether
the game runs without this due to an unrelated bug that prevents the
game from running at all. Reported.
- libs/libkf5kdelibs4support-data installs
/usr/share/locale/kf5_all_languages ; again, KDE applications seem
to work fine without any of these files.
- locales has /usr/share/locale/locale.alias, which is just a symlink
to /etc/locale.alias. Software *already* needs to work without this.
So, in summary: every class of file installed in this by any package in
Debian is something the package runs fine without, unless some package
is installing gettext files *and* using something other than gettext to
parse them *and* failing to handle them being missing, which seems
exceedingly unlikely as applications generally need to cope with
arbitrary languages being available or unavailable at runtime, and
shouldn't have a hardcoded list of translation files they expect to
exist.
Based on that, I think it's very unlikely that a single bug will arise
from adding this policy change. I think it'd be safe to say "must" here.
But if people would nonetheless like this changed to "should", I can do
that.
- Josh Triplett
