Theodore Ts'o wrote: > Currently e2fsprogs recommends e2fsprogs-l10n. In Debian Policy, it states: > > This declares a strong, but not absolute, dependency. > > The Recommends field should list packages that would be found > together with this one in all but unusual installations. > > It seems to me that po translation files are borderline considering it > a "strong dependency". Is it really "the most unusual installations"? > I wouldn't think so, but I acknowledge my privilege coming from a > native English speaker. > > Given recent discussions about depends vs recommends vs suggests > inflation, I'm thinking about down-prioritizing e2fsprogs-l10n from > recommends to suggests. > > Thoughts, comments?
The primary distinction would be whether they get installed by default. And I think it makes sense for support for non-English languages to get installed by default, because the *only* thing such packages typically do is take up space. There are a variety of reasons people don't want a package installed. For packages that run a service or affects how the system behaves or similar, it's much more debatable whether to install them by default, even if doing so makes some functionality Just Work. But that seems like *less* of a concern for things that just take up additional space but don't otherwise cause any issues. The "all but unusual installations" case here is "systems that have no non-English users *and* that care deeply enough about disk usage that a few MB here or there matters". (An example of such a use case: creating a container image or similar, where size can directly impact start time or download time.) In the future, I hope we have a more fine-grained mechanism that allows saying "X recommends Y if Z is installed" (or even "X depends on Y if Z is installed"). We could use that to have some "signaling" packages like l10n-xx or l10n-any (the former depending on the latter), such that examplepackage can have `Recommends: examplepackage-l10n [if l10n-any]` or `Recommends: examplepackage-l10n-xx [if l10n-xx]`. But until we have a mechanism like that, I think it makes sense to say that "support for non-English languages" is in general a Recommends as long as pulling it in just means taking up additional installed size on disk. We could also consider adding explicit documentation in Policy that "Packages must not require the existence of any files in /usr/share/locale/ in order to function in a C or C.UTF-8 locale.", which would make it explicit that sysadmins can use things like dpkg exclusions to omit all of /usr/share/locale when building tiny images. That might reduce the pressure on packagers to split out -l10n- packages. - Josh Triplett
