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?

- Ted



--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Le 2024-12-05 16:43, Theodore Ts'o a écrit :

Given recent discussions about depends vs recommends vs suggests
inflation, I'm thinking about down-prioritizing e2fsprogs-l10n from recommends to suggests.

Thoughts, comments?

There are existing task-<language> and task-<language>-desktop
metapackages, but currently only live-task-localisation depends
(actually, recommends) on them. That live-task-localisation doesn't
currently depend/recommend/suggest any *-l10n package, possibly because
it wouldn't make much sense to install all of them (especially on
limited live media space) if the corresponding package is not installed.

Maybe having something like a more generic task-l10n that would replace live-task-localisation and also configure apt preferences to raise
"suggests" dependency relations targeting *-l10n packages to
"recommends" would help, but that would be a new apt feature.

That new configuration feature could be made to allow the other way as
well, downgrading "recommends" on a set of package to "suggests" to
satisfy those who complain about too many recommendations. This way
might be easier to deploy as it doesn't require any (probably impopular)
change in current dependency relations.

--
Julien Plissonneau Duquène

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Dec 05, 2024 at 08:55:35PM +0100, Roland Clobus wrote:

How about adding the translations to the main package e2fsprogs, and let the package 'localepurge' remove them? For people who care about installed size, that package helps to remove undesired translation files. (Although all translations will then be downloaded while installing e2fsprogs)

I'd like to hear from people who manage container
images. They were the ones whose complaints led to the separation of
how e2fsprogs-l10n from e2fsprogs in the first place. I'm not a
docker expert, but I believe how the image layering works means that
even using localepurge would result in locale files being downloaded.
I'm not sure the resulting disk space gets charged out of the
container, though.

I will note that the package description of localepurge does very much
have a "beware of the leopard" vibe....

This tool is a hack which is *not* integrated with the system's
package management system and therefore is not for the faint of heart.
Its interference can provoke strange, but usually harmless, behavior in
programs related to apt/dpkg, such as dpkg-repack, reportbug, etc.
Responsibility for its usage and possible breakage of the system
therefore lies in the system administrator's hands.

- Ted

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Dec 05, 2024 at 01:28:11PM -0500, Theodore Ts'o wrote:

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

Personally, I am quite sympathetic to the argument about wasting disk
space, and I care about the size of the base system myself. But I think
the primary affordance we make for such use cases is for core system
packages to have separate -l10n packages *at all* (whereas many packages
just ship localization directly in the main package).

In the future, if users can easily filter out locale data, we could
decide that that's the easier path to support such users, and that fewer package maintainers need to maintain separate -l10n packages.

I also think that defaults should cater to the cohort of users who are
less inclined to (or less able to) do customization, because other users
can easily override the defaults.

I think, on balance, users should be able to get messages in their
preferred locale by default, and users who care deeply about disk space
can always remove Recommended packages or not install them in the first
place.

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.

https://bugs.debian.org/1089110

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Theodore Ts'o wrote:

On Thu, Dec 05, 2024 at 01:02:29PM -0800, Josh Triplett wrote:

https://bugs.debian.org/1089110

I've looked at this bug, but unlessed I missed something, this seems
to be "rm -rf /usr/share/locale" shouldn't cause binaries to core
dump. I'm guessing this is the reason for the "beware of the leopard"
vibe in the documentation of localepurge package? I didn't realize
binaries would be so ill-behaved as to crash if the locale files were missing. Sigh...

This policy proposal does even less than that; it just says that packages must not require files on /usr/share/locale *when using a C or C.UTF-8 locale*. It makes no promises about other configurations.

Perhaps we should have a separate debian policy proposal which
explicitly makes a requirement that the locale files should be
separated for anything installed by default by debootstrap, and what
the dependency priority of the *-l10n package should be?

We could. On the other hand, with the policy update I've proposed, we could also endorse the use of dpkg exclusions for this instead.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/5/24 6:28 PM, Josh Triplett wrote:

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 might misremember but I don't think there's a guarantee that C is
actually English, no? I.e. it would be legit for a program to output in
French or Chinese in the C.UTF-8 locale and have a translation to English?

Kind regards
Philipp Kern

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Dec 05, 2024 at 01:02:29PM -0800, Josh Triplett wrote:

Personally, I am quite sympathetic to the argument about wasting disk
space, and I care about the size of the base system myself. But I think
the primary affordance we make for such use cases is for core system
packages to have separate -l10n packages *at all* (whereas many packages
just ship localization directly in the main package).

Many, but not all. For example, bash and coreutils ship
/usr/share/locale files in the base package.

I recently added a "rm -rf /usr/share/locale" to the build
kvm-xfstests test appliance, and it saved 16 megabytes in the
compressed qemu-img test appliance. (And this was *without* my
installing any *-l10n packages, including not installing
e2fsprogs-l10n.)

I agree that we should take a more opinioned stance in Debian Policy.

https://bugs.debian.org/1089110

I've looked at this bug, but unlessed I missed something, this seems
to be "rm -rf /usr/share/locale" shouldn't cause binaries to core
dump. I'm guessing this is the reason for the "beware of the leopard"
vibe in the documentation of localepurge package? I didn't realize
binaries would be so ill-behaved as to crash if the locale files were
missing. Sigh...

Perhaps we should have a separate debian policy proposal which
explicitly makes a requirement that the locale files should be
separated for anything installed by default by debootstrap, and what
the dependency priority of the *-l10n package should be?

- Ted

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Mike Hommey wrote:

On Thu, Dec 05, 2024 at 01:02:29PM -0800, Josh Triplett wrote:

In the future, if users can easily filter out locale data, we could
decide that that's the easier path to support such users, and that fewer package maintainers need to maintain separate -l10n packages.

The future is 14 years old. https://raphaelhertzog.com/2010/11/15/save-disk-space-by-excluding-useless-files-with-dpkg/

I'm aware, and that was the feature I was talking about in this thread.
The point was that that isn't *guaranteed* to work, by Policy, hence the
Policy proposal to say that packages should work with those files
removed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Dec 05, 2024 at 01:02:29PM -0800, Josh Triplett wrote:

In the future, if users can easily filter out locale data, we could
decide that that's the easier path to support such users, and that fewer package maintainers need to maintain separate -l10n packages.

The future is 14 years old. https://raphaelhertzog.com/2010/11/15/save-disk-space-by-excluding-useless-files-with-dpkg/

Mike

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 6 Dec 2024 07:12:44 +0900, Mike Hommey <mh@glandium.org>
wrote:

On Thu, Dec 05, 2024 at 01:02:29PM -0800, Josh Triplett wrote:

In the future, if users can easily filter out locale data, we could
decide that that's the easier path to support such users, and that fewer
package maintainers need to maintain separate -l10n packages.

The future is 14 years old. https://raphaelhertzog.com/2010/11/15/save-disk-space-by-excluding-useless-files-with-dpkg/

And I never got it working. Tried to talk to the dpkg maintainer but
got ghosted eventually. That's a clear usability issue.

Greetings
Marc
--
---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-12-05, Theodore Ts'o <tytso@mit.edu> wrote:

Given recent discussions about depends vs recommends vs suggests
inflation, I'm thinking about down-prioritizing e2fsprogs-l10n from recommends to suggests.

I do think down prioritizing them makes sense in the current setup.

Though I do also think we have a hole in our dependency system here.

if I set my system up to be in entish, I don't want to chase translation
files all over the package system. It should somehow just happen.

This is just me writing something in a email hoping that someone else
picks it up (this time)

Package: foo
Recommends: foo-LANG <condition: LANG>

And then somehow tell apt how to expand LANG for all relevant languages.

/Sune

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 2024-12-05 at 13:28 -0500, Theodore Ts'o wrote:

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.

Localization is not only about disk space, but also manuals, spell
checking, input method tools, fonts etc. being scattered all over the
system.

It does not make sense that everyone has to select his spell checker
language from 50+ options he does not speak.

Particularly annoying is that Thai terminal (xiterm+thai), which is preinstalled in Debian desktop and appears in launchers such as Gnome
Shell when searching for terminals.
Most people never use it. I even doubt that many Thai users use it
since it is ancient and any terminal should support UTF-8 by now.

Regards
Stephan

PS: I use various languages (de_DE, en_US, de_CH and id_ID), but I
prefer to install them manually.

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQRB1rjSpCJd8a7h6mNgNUJZCjx8YgUCZ1LnEwAKCRBgNUJZCjx8 YhT1AP9VqLTX5yIKARFQEHNZvcppcVRWIxXC1K5toYlR01l6dAEAg5XiafUFS0Vx GIacJMWYLYqu9IT0LHPUGNVmeBRczAs=
=HI8i
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Dec 6, 2024 at 6:59 AM Stephan Verbücheln <verbuecheln@posteo.de> wrote:

Localization is not only about disk space, but also manuals, spell
checking, input method tools, fonts etc. being scattered all over the
system.

It does not make sense that everyone has to select his spell checker
language from 50+ options he does not speak.

Particularly annoying is that Thai terminal (xiterm+thai), which is preinstalled in Debian desktop and appears in launchers such as Gnome
Shell when searching for terminals.

To clarify, this happens if you use the Live ISO (that uses Calamares)
but not if you use the default netinst ISO.

Thank you,
Jeremy Bícha

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi!

On Fri, 2024-12-06 at 09:22:43 -0000, Sune Vuorela wrote:

Though I do also think we have a hole in our dependency system here.

I think most of the needed pieces are there already though.

if I set my system up to be in entish, I don't want to chase translation files all over the package system. It should somehow just happen.

This is just me writing something in a email hoping that someone else
picks it up (this time)

Package: foo
Recommends: foo-LANG <condition: LANG>

And then somehow tell apt how to expand LANG for all relevant languages.

Something like the following should already work:

$ aptitude install \
'?narrow(?narrow(~Gculture::valarin,?reverse-Recommends(~i)),!~i)'

Although of course it's not very user friendly, and it would need to
expanded to cover virtual packages for example. But I guess it could
be wrapped in some kind of l10n support helper. Or the packaging
frontends could be extended to support this with an easier to use
term.

Thanks,
Guillem

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Josh" == Josh Triplett <josh@joshtriplett.org> writes:

Josh> In the future, I hope we have a more fine-grained mechanism
Josh> that allows saying "X recommends Y if Z is installed" (or even
Josh> "X depends on Y if Z is installed").

I'd really like this, both for Debian work and for downstream work on
Debian derived systems.

--Sam

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Ted,

On Thu, Dec 05, 2024 at 01:28:11PM -0500, Theodore Ts'o wrote:

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.

I suggest that you completely ignore containers and servers for the
purpose of judging Recommends vs Suggests, but take them into account
for judging Depends vs Recommends. Basically all of the container image creation tools I've interacted with immediately turn off installation of Recommends so to them Recommends and Suggests behave the same. The slim
image variant for docker/podmand goes beyond and deletes much of /usr/share/doc. For server deployments, what is in charge of deciding
whether to install e2fsprogs-l10n is probably Ansible, Chef, Puppet or something along those lines. To these areas, the crucial step has been separating the translations into an optional component. Thank you.

If you disregard these deployments, e2fsprogs-l10n suddenly becomes
relevant to most usual installations. Admittedly, I never install it.

The primary values in action I see here are:
* Enable advanced people to trim their installations by separating
non-essential space consuming parts into optional packages (i.e.
exactly what happened with e2fsprogs-l10n).
* Have it just work by default (i.e. Recommends).

I no longer buy the argument for conserving space when a typical NixOS installation takes 100GB and people are happy with it. As long as we
provide the mechanisms to trim installations, those who need to conserve
space should be doing the work of opting out.

My impression of earlier discussions of this matter is that this opinion
should achieve at least rough consensus, but maybe things changed.

Helmut

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/6/24 6:40 AM, Helmut Grohne wrote:

I no longer buy the argument for conserving space when a typical NixOS installation takes 100GB and people are happy with it. As long as we
provide the mechanisms to trim installations, those who need to conserve space should be doing the work of opting out.

While I had many problems with too small disks on Cloud servers running
NixOS, we are also talking about closer to 20-25 GB than 100 GB. (For
servers with a couple of services running and also having been upgraded
a couple of times - albeit with GC running regularly.)

Kind regards
Philipp Kern

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)