On Thu, Dec 05, 2024 at 09:28:34AM -0800, Josh Triplett wrote:
> 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.
Well, it seems most of the people who are complaining about the
dependency (Depends / Recommends / Suggests) inflation are primarily
complaining about the disk space thatis involved. Even
co-installation of relatively small files (hundreds of kilobytes) has
been enough to cause complaints. Coming from a storage background
where 5 EiB of free space is a critical low storage condition leading
to SRE's getting paged, I'm not terribly sympathetic to that argument,
but people do seem to be very concerned about installation of dormant
packages even if "all" they do is consume space.
> 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 case of e2fsprogs, server and container image *really* don't
have any need of translations --- and in fact, from my perspective,
it's often actively harmful, when users send me e2fsck logs in
Vietnamese and I have to try to figure out was going on.
So if what we are talking about numbers, there are probably several
orders of magnitude more server, VM, and container instances where
e2fsprgs-l10n is really unecessary. Hence I'd argue that this is a
more appropriate description of the priority of e2fsprogs-l10n:
This is used to declare that one package may be more useful with
one or more others. Using this field tells the packaging system and
the user that the listed packages are related to this one and can
perhaps enhance its usefulness, but that installing this one
without them is perfectly reasonable.
> 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.
I agree that we should take a more opinioned stance in Debian Policy.
Personally, I don't care about the cost ($0.72 USD per year for
e2fsprogs in cloud VM storage, for exaple). But apparently there
*are* people who care about the excess size pf the root file system,
and so it would be useful for us to come to consensus as a project.
- Ted
