RFC: "Recommended bloat", and how to possibly fix it

[Aaron Rainbolt]

Hello, and thanks for your time.

I've been a Debian user and contributor for a while, and have noticed a
rather frustrating issue that I'm interested in potentially
contributing code to fix. The issue is what I call "Recommended bloat",
which in short is what happens when you install a package with all of
its recommended packages, and end up with a whole lot of stuff installed
that you don't want and that the package you actually wanted probably
didn't even need.

According to the Debian Policy Manual, section 7.2, the Recommends
field in Debian packages "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." While
this is a very useful definition, the actual way in which Recommends
are used seems to differ substantially from this.

More often than not, it seems packagers treat the Recommends field as a
place to list things that aren't dependencies but that the packager,
for whatever reason, wants installed alongside the package they're
working on. This results in packages being installed that many users
may consider entirely useless or even detrimental, but that nonetheless
end up installed as if they were strong-but-not-absolute dependencies.

My favorite package to "pick on" when illustrating this is
"diffoscope". Its job is to do "deep comparisons" of tons of different
file types. Realistically, a user who's using diffoscope will only want
a subset of its functionality (the person who wants to compare kernel
builds may not care about the ability to compare Android APKs, for
instance). Yet if you try to install diffoscope with a simple `sudo apt
install diffoscope`, it tries to pull in an entire army of
various packages, including `supermin`, `mono-runtime`,
`qemu-system-x86`, `syslinux`, `default-jre`, `r-base-core`, and
several Android-related packages. These are all pulled in because of
diffoscope's rather overkill set of recommends, and IMO it's rather
hard to say that all of these things would be found together with
diffoscope in all but unusual installations.

If this was just a diffoscope problem, it would be easy to just file a
bug asking that most of these packages be demoted to Suggests, but this
is a much more pervasive issue, as evidenced by the fact that the
live-build manual has special instructions for how to disable the
installation of *all* recommended packages when building a live
image[1]. I have built live images that ended up with all sorts of
weird packages installed on them, which issue was resolved by disabling
the installation of recommended packages.

The issue with resorting to things such as `apt install
--no-install-recommends` is that the Recommends field is not always
used as a catch-all for packages that the packager wants installed by
default. Sometimes it is used in a spec-compliant manner, and in those
instances the use of `--no-install-recommends` and similar features can
cause serious problems. The aforementioned live-build manual mentions
this, warning that one probably should explicitly install `user-setup`
and `sudo` in images that they build if they want things to work
properly. While there are situations in which one legitimately doesn't
want even those packages, those situations are relatively rare - as the
Debian Policy Manual states, these packages are needed in all but
unusual installations.

Furthermore, the current (ab)use of Recommends in Debian packages
illustrates something important - there is a real need for packagers to
specify packages that should automatically be installed alongside
another package, but that aren't necessarily strong dependencies. Using
diffoscope again as an example, it's reasonable that the diffoscope
maintainers want *all* of diffoscope's functionality to "just work"
out of the box, even if that means installing over three and a half
gigabytes of packages to do it.[2] This may not be policy-compliant,
but demoting these packages to the "Suggests" field doesn't feel right.
Should a user who just wants to compare things have to figure out the
right combo of packages to make diffoscope work for their particular
use case?[3] There's also the question of logistics - going through and
"fixing" all of the packages with overkill Recommends could be a
massive undertaking, and it's more than likely that there will be some
packagers who won't be thrilled with the changes.

With all this in mind, I'd like to call some attention to a feature
request made by Patrick Schleizer some time ago, whom I've copied on
this email. The feature request suggests the addition of a new field to
Debian's binary dependency relationship fields, "Weak-Depends".[4] In
Patrick's own words, Weak-Depends "[d]eclares a weak dependency. Most
users of this package may benefit from installing packages listed in
this field, but can have reasonable functionality without them." The
exact way in which this would be implemented is that Weak-Depends
packages would get installed when using `apt install
--no-install-recommends package`, but any package listed there could be
removed without removing the package which referenced the Weak-Depends.

An astute reader will notice that this sounds an awful lot like what
the Recommends field is supposed to be for... because it is! This leads
into the second half of the change I would like to suggest making,
which is that the definition of "Recommends" in the Debian Policy
Manual be changed to reflect how it is actually used. "Recommends" is
used to declare packages which provide useful benefits when installed
alongside another package, and is typically used to make it so that
installing one package results in the installation of another package.
That's what its definition in Debian policy should reflect.
"Weak-Depends" would then basically take over the role "Recommends"
was originally intended to play. The policy manual would include a note
on "Weak-Depends", stating something like "if the package declaring the
dependency is still reasonably useful when the dependency is removed,
carefully consider if Recommends is a better fit here". Recommends
would also have a note such as "if the package declaring the dependency
is rendered significantly impaired when the dependency is removed,
carefully consider if Weak-Depends is a better fit here". This is
conceptually similar to the difference between Breaks and Conflicts,
where both of them will keep two packages from being fully installed at
the same time, but one is "stronger" than the other and the two have
slightly different behavior. Weak-Depends would basically just be a
stronger "Recommends".

Obviously, there are still edge cases where a user may want all
optional packages, even Weak-Depends packages, to stay out of the
picture. For these scenarios, a `--no-install-weak-depends` flag could
be added to apt, and dpkg could be made to gripe but not fail if the
user tries to install a package without its Weak-Depends being
installed alongside.

Some of the advantages of this solution include:

* It requires comparatively few changes to initially implement. All
existing packages in the Debian repository will be compliant with a
Debian Policy Manual update that adds Weak-Depends, without changes.
Packagers can start using Weak-Depends if they want to or if a bug
report requests that they do. Some of the packages that would need to
change to implement this would be dpkg, apt, possibly the libraries
they depend on, and live-build. There's probably others here, but
nonetheless it wouldn't require a massive overhaul of the whole
archive to make it start working, the way a mass-"demote to Suggests"
operation would.
* If widely used across the Debian archive, people who want to avoid a
bloated system without ending up with a severely wonky system can
use `--no-install-recommends` to install packages, yet still end up
with packages that they really needed to have but probably didn't
know they needed.
* The default behavior of apt will still be to install recommended
packages by default, meaning that almost nothing will change from a
user standpoint when running `apt install package`. There won't be
any weird surprises like "why does installing diffoscope only install
the core engine but leave out everything that's needed for diffoscope
to do anything useful?"

So, in summary, I would like to suggest the following changes, to help
resolve the "Recommended bloat" issue.

* Add a "Weak-Depends" field to the list of binary dependency control
fields in the Debian Policy Manual section 7.2, with a definition
very similar to the existing definition for "Recommends".
* Change the definition of the "Recommends" field to match the way
the field is oftentimes used in the Debian archive.
* Add support for the "Weak-Depends" field to apt, dpkg, and other
packaging-related tools that need it (such as aptitude, live-build,
and potentially others). This support would include recognition of
the field in control files, non-fatal warnings in dpkg when a
Weak-Depends is missing, and the addition of
`--no-install-weak-depends` options to allow people to skip
installing them.
* Suggest that all active package maintainers in Debian review the
packages they maintain and see if they feel there are some packages
that should be promoted from "Recommends" to "Weak-Depends".
* (Potentially?) Scan the Debian archive and see if there are
dependencies that should be promoted from "Recommends" to
"Weak-Depends". This would probably be something that interested
Debian Developers and other volunteers could slowly chip away at, as
they had time and the desire to do so.

Thanks for taking the time to read this!

[1]: https://live-team.pages.debian.net/live-manual/html/live-manual/customizing-package-installation.en.html section 8.4.3.
[2]: On my Debian Bookworm XFCE machine, `sudo apt install diffoscope`
reports "After this operation, 3,624 MB of additional disk space
will be used."
[3]: This particular situation could probably be fixed with the help of
some metapackages, but that's beside the point.
[4]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942303

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Aaron Rainbolt (2024-11-06 00:35:59)

According to the Debian Policy Manual, section 7.2, the Recommends field in
Debian packages "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." While this is a very useful
definition, the actual way in which Recommends are used seems to differ
substantially from this.

then you should file bugs against the packages that violate this part of
policy.

If this was just a diffoscope problem, it would be easy to just file a bug
asking that most of these packages be demoted to Suggests, but this is a much
more pervasive issue, as evidenced by the fact that the live-build manual has
special instructions for how to disable the installation of *all* recommended
packages when building a live image[1]. I have built live images that ended
up with all sorts of weird packages installed on them, which issue was
resolved by disabling the installation of recommended packages.

On my system, I have apt configured to not install Recommends by default
because I want to manually pick what to install when I install new things.
Oftentimes I find the extra things that get installed too bloated for my taste,
so I sympathize with your quest, but I do not agree with your solution.

Furthermore, the current (ab)use of Recommends in Debian packages illustrates
something important - there is a real need for packagers to specify packages
that should automatically be installed alongside another package, but that
aren't necessarily strong dependencies. Using diffoscope again as an example,
it's reasonable that the diffoscope maintainers want *all* of diffoscope's
functionality to "just work" out of the box, even if that means installing
over three and a half gigabytes of packages to do it.[2] This may not be
policy-compliant, but demoting these packages to the "Suggests" field doesn't
feel right. Should a user who just wants to compare things have to figure
out the right combo of packages to make diffoscope work for their particular
use case?[3] There's also the question of logistics - going through and
"fixing" all of the packages with overkill Recommends could be a massive
undertaking, and it's more than likely that there will be some packagers who
won't be thrilled with the changes.

This argument goes both ways. Your proposed solution has the same drawbacks. To
properly implement your solution, you still have to go through and fix all of
the packages with overkill Recommends which is a massive undertaking and it's
not unlikely that there will be some packagers who won't be thrilled with the
change (as it usually is the case for any kind of change you propose to
somebody's package).

Weak-Depends would basically just be a stronger "Recommends".

I don't think that the solution to your problem is to make the
Recommends/Suggests logic more granular. You still have to convert all the
packages which you think have too many Recommends. Even assuming that their
maintainers agree, instead of doing that work, why not invest that time in
finding a solution using the existing mechanisms instead? You mentioned that
meta-packages are besides the point. Why? Have one package diffoscope and one
package diffoscope-full and you could even have a package diffoscope-minimal
and there you have user-selectable granularity.
Any good proposal also includes disadvantages. Any suggestion to change
something should come with an attempt to weigh the benefits against the costs.
In your mail you do not make an argument about the costs of your proposed
change. I'd argue, that the cost of your proposal are too high. Especially when
comparing that cost to using the existing packaging mechanisms to achieve
essentially the same thing.

* It requires comparatively few changes to initially implement.

I strongly disagree. I think you are estimating the number of packages which
attempt messing around with Debian packages and their dependencies and which
would have to receive a patch to support a new field.

All
existing packages in the Debian repository will be compliant with a
Debian Policy Manual update that adds Weak-Depends, without changes.

I thought your proposal was to make Weak-Depends effectively what Recommends is
today?

Packagers can start using Weak-Depends if they want to or if a bug
report requests that they do. Some of the packages that would need to
change to implement this would be dpkg, apt, possibly the libraries
they depend on, and live-build.

Yes. And sbuild, python-apt, aptitude, mmdebstrap, debootstrap, cdebootstrap,
debhelper, cdbs, lintian, pbuilder, dose3, wanna-build, dak, python-debian,
libconfig-model-dpkg-perl, augeas, haskell-debian, dh-exec, autopkgtest and
very many tools in devscripts like build-rdeps, debrebuild, wrap-and-sort...
And then there is all the work that our downstream distros need to do for their
tooling as well.

Do you plan to send patches?

There's probably others here, but
nonetheless it wouldn't require a massive overhaul of the whole
archive to make it start working, the way a mass-"demote to Suggests"
operation would.

I disagree. The change you are proposing requires core changes to very many
tools, potentially creating new bugs and lots of friction going forward.
A mass-demote, if you want to drive that, can be done package-by-package
at your own time without breaking the archive, our tooling and our downstreams.

* Change the definition of the "Recommends" field to match the way
the field is oftentimes used in the Debian archive.

Please do it the other way round. File bugs where packages do not follow policy
and use workarounds like your meta-package idea in other cases.

* Suggest that all active package maintainers in Debian review the
packages they maintain and see if they feel there are some packages
that should be promoted from "Recommends" to "Weak-Depends".

Your proposal would be much simpler if it would just be this item but about
demoting Recommends to Suggests. I get the feeling, from how you are writing
this, that you expect others to do the work for you? I fear that little change
will happen unless you are putting in the work yourself. File bugs and attach
patches.

* (Potentially?) Scan the Debian archive and see if there are
dependencies that should be promoted from "Recommends" to
"Weak-Depends". This would probably be something that interested
Debian Developers and other volunteers could slowly chip away at, as
they had time and the desire to do so.

Why am I so negative? I was one of the main driver behind the introduction of
the Build-Profiles field. It was a lot of pain to do this and it took a couple
of years. But to get the desired functionality, there was not much else that
could be done than to add a new field. In your case, there are alternatives
using the existing mechanisms. I suggest you instead think about how you can
use the existing machinery to achieve the desired effect. I fear you are vastly
underestimating the crazy amount of work that introducing a new dependency
relationship field incurs. Please try having a more realistic look at the
cost/benefit ratio of what you are proposing here.

Thanks!

cheers, josch

[Aaron Rainbolt]

Partially top-posting because there are some assumptions here that need
cleared up.

Hi Johannes, and thanks for your feedback. I would like to point out
that I explicitly said in the very start of my email, that this was
something I was "interested in potentially contributing code to fix." I
see this part got omitted from what you quoted of my email, so it may
have gone unnoticed. I'm fully intend to implement and test much or
even most of the code require to make this happen should it be
considered desirable. So in reply to your "Do you plan to send
patches?" questions, yes, I intended to send patches from the moment I
started writing the email. It's generally understood and oftentimes
spelled out in open-source projects that one should discuss and get
feedback on a large change before even starting to implement it, which
is exactly what I'm doing here. I know that my proposal, as given, is
likely to not be accepted as is and may even be rejected altogether,
which is why I said "potentially". I would appreciate if you would look
at my suggestion in this light rather than assuming I'm just coming up
with a "great idea" that I expect everyone else to work on without any
further help from me.

It may also help to look at this as an initial "testing the waters"
conversation starter, and not as a proposal in its entirety. That's
what the DEP process is for. In your reply you mention "any good
proposal includes disadvantages", which is true. This doesn't have
those because it's not meant to be a formal proposal. The only reason I
sent this on the mailing lists rather than simply starting a
conversation on IRC is because I wanted it to get wider visibility.

The rest of my replies are inline.

On Wed, 06 Nov 2024 02:28:33 +0100

Post by Johannes Schauer Marin Rodrigues
Hi,
Quoting Aaron Rainbolt (2024-11-06 00:35:59)

Post by Aaron Rainbolt
According to the Debian Policy Manual, section 7.2, the Recommends
field in Debian packages "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."
While this is a very useful definition, the actual way in which
Recommends are used seems to differ substantially from this.

then you should file bugs against the packages that violate this part
of policy.

Post by Aaron Rainbolt
If this was just a diffoscope problem, it would be easy to just
file a bug asking that most of these packages be demoted to
Suggests, but this is a much more pervasive issue, as evidenced by
the fact that the live-build manual has special instructions for
how to disable the installation of *all* recommended packages when
building a live image[1]. I have built live images that ended up
with all sorts of weird packages installed on them, which issue was
resolved by disabling the installation of recommended packages.

On my system, I have apt configured to not install Recommends by
default because I want to manually pick what to install when I
install new things. Oftentimes I find the extra things that get
installed too bloated for my taste, so I sympathize with your quest,
but I do not agree with your solution.

Post by Aaron Rainbolt
Furthermore, the current (ab)use of Recommends in Debian packages
illustrates something important - there is a real need for
packagers to specify packages that should automatically be
installed alongside another package, but that aren't necessarily
strong dependencies. Using diffoscope again as an example, it's
reasonable that the diffoscope maintainers want *all* of
diffoscope's functionality to "just work" out of the box, even if
that means installing over three and a half gigabytes of packages
to do it.[2] This may not be policy-compliant, but demoting these
packages to the "Suggests" field doesn't feel right. Should a user
who just wants to compare things have to figure out the right combo
of packages to make diffoscope work for their particular use
case?[3] There's also the question of logistics - going through and
"fixing" all of the packages with overkill Recommends could be a
massive undertaking, and it's more than likely that there will be
some packagers who won't be thrilled with the changes.

This argument goes both ways. Your proposed solution has the same
drawbacks. To properly implement your solution, you still have to go
through and fix all of the packages with overkill Recommends which is
a massive undertaking and it's not unlikely that there will be some
packagers who won't be thrilled with the change (as it usually is the
case for any kind of change you propose to somebody's package).

Specifically for this point, the reason I thought that my proposed
solution would be superior to refactoring packages or demoting things
to Suggests is because both of those solutions require somewhat
invasive or significantly functionality-modifying changes to packages.
The suggested Weak-Depends field's end goal was to allow resolving the
problem with a very small change to each package that needed help,
which change would have almost no functional effect on the package but
would alleviate the problem. If it was my package someone wanted to
modify, I know I'd be much more amicable to a solution that worked that
way than to a functionality-changing modification or a packaging
overhaul.

Post by Johannes Schauer Marin Rodrigues

Post by Aaron Rainbolt
Weak-Depends would basically just be a stronger "Recommends".

I don't think that the solution to your problem is to make the
Recommends/Suggests logic more granular. You still have to convert
all the packages which you think have too many Recommends. Even
assuming that their maintainers agree, instead of doing that work,
why not invest that time in finding a solution using the existing
mechanisms instead? You mentioned that meta-packages are besides the
point. Why? Have one package diffoscope and one package
diffoscope-full and you could even have a package diffoscope-minimal
and there you have user-selectable granularity.

This gets into what I just mentioned about packaging overhauls. Sure,
diffoscope *could* be refactored so that there was a base "engine"
package, a number of metapackages for different use cases, and a "full"
metapackage that would pull in all 3.5 GB of packages like it does
today. That would even be a great solution, and for this particular
package it would work even better than a Weak-Depends field. So why did
I consider it was beside the point? Because of what I just mentioned -
metapackage-based solutions are for cases that are too complicated for
Weak-Depends to handle perfectly. It would do the job, it just wouldn't
achieve a "shining city on the hill" result the way a metapackage-based
solution would.

Post by Johannes Schauer Marin Rodrigues
Any good proposal also includes disadvantages. Any suggestion to
change something should come with an attempt to weigh the benefits
against the costs. In your mail you do not make an argument about the
costs of your proposed change. I'd argue, that the cost of your
proposal are too high. Especially when comparing that cost to using
the existing packaging mechanisms to achieve essentially the same
thing.

See my note at the top about this being a conversation starter, and not
a formal proposal.

Post by Johannes Schauer Marin Rodrigues

Post by Aaron Rainbolt
* It requires comparatively few changes to initially implement.

I strongly disagree. I think you are estimating the number of
packages which attempt messing around with Debian packages and their
dependencies and which would have to receive a patch to support a new
field.

Post by Aaron Rainbolt
All
existing packages in the Debian repository will be compliant with
a Debian Policy Manual update that adds Weak-Depends, without
changes.

I thought your proposal was to make Weak-Depends effectively what
Recommends is today?

Yes. My point is that Recommends will still be able to function the way
it does today even with Weak-Depends in existence. But packages can
also migrate to using Weak-Depends in addition.

Post by Johannes Schauer Marin Rodrigues

Post by Aaron Rainbolt
Packagers can start using Weak-Depends if they want to or if a bug
report requests that they do. Some of the packages that would
need to change to implement this would be dpkg, apt, possibly the
libraries they depend on, and live-build.

Yes. And sbuild, python-apt, aptitude, mmdebstrap, debootstrap,
cdebootstrap, debhelper, cdbs, lintian, pbuilder, dose3, wanna-build,
dak, python-debian, libconfig-model-dpkg-perl, augeas,
haskell-debian, dh-exec, autopkgtest and very many tools in
devscripts like build-rdeps, debrebuild, wrap-and-sort... And then
there is all the work that our downstream distros need to do for
their tooling as well.

*This* is the kind of feedback I was hoping for. This is very useful
info to have, thank you for pointing this out.

Post by Johannes Schauer Marin Rodrigues
Do you plan to send patches?

Yes, as noted above.

Post by Johannes Schauer Marin Rodrigues

Post by Aaron Rainbolt
There's probably others here, but
nonetheless it wouldn't require a massive overhaul of the whole
archive to make it start working, the way a mass-"demote to
Suggests" operation would.

I disagree. The change you are proposing requires core changes to
very many tools, potentially creating new bugs and lots of friction
going forward. A mass-demote, if you want to drive that, can be done
package-by-package at your own time without breaking the archive, our
tooling and our downstreams.

Post by Aaron Rainbolt
* Change the definition of the "Recommends" field to match the way
the field is oftentimes used in the Debian archive.

Please do it the other way round. File bugs where packages do not
follow policy and use workarounds like your meta-package idea in
other cases.

Post by Aaron Rainbolt
* Suggest that all active package maintainers in Debian review the
packages they maintain and see if they feel there are some
packages that should be promoted from "Recommends" to
"Weak-Depends".

Your proposal would be much simpler if it would just be this item but
about demoting Recommends to Suggests. I get the feeling, from how
you are writing this, that you expect others to do the work for you?
I fear that little change will happen unless you are putting in the
work yourself. File bugs and attach patches.

Post by Aaron Rainbolt
* (Potentially?) Scan the Debian archive and see if there are
dependencies that should be promoted from "Recommends" to
"Weak-Depends". This would probably be something that interested
Debian Developers and other volunteers could slowly chip away at,
as they had time and the desire to do so.

Why am I so negative? I was one of the main driver behind the
introduction of the Build-Profiles field. It was a lot of pain to do
this and it took a couple of years. But to get the desired
functionality, there was not much else that could be done than to add
a new field. In your case, there are alternatives using the existing
mechanisms. I suggest you instead think about how you can use the
existing machinery to achieve the desired effect. I fear you are
vastly underestimating the crazy amount of work that introducing a
new dependency relationship field incurs. Please try having a more
realistic look at the cost/benefit ratio of what you are proposing
here.

I think I can summarize much of what you're saying as "why not make it
work with the existing infrastructure?" To be clear, I fully agree that
the existing infra *can* be used to fix the issue without further
features. Should it? I explained the reasons I thought perhaps it
shouldn't in my initial email. I don't expect people will want to
change their packages to make their Recommends fields policy-compliant,
and while I certainly can use the policy to force people to "do it
right", it seemed to me like the policy violations were an indicator
that the policy was wrong and the existing machinery insufficient for
packagers to easily express what they were trying to express in their
packaging code. I gather from your email that this is a larger of a job
than I made it sound like (which makes sense since I didn't spend a
huge amount of time considering what would need changes since this is,
after all, just a conversation starter), so maybe that means that my
suggestion is not one that is ultimately worth it. The fact that you've
been down this road already is also very good to know.

I would like to point out that, as you are well aware of, developers
don't appreciate feedback that is intentionally worded in a highly
negative fashion. I'm no different from most others in this respect. I
think the information you've shared is valuable, especially the
feedback on the amount of work it would take to implement this
(something I did not fully consider when writing this since this was
just intended to be a "hey here's an idea I'm interested in, I wonder
what everyone else thinks" post). But the harsh and somewhat hurtful
assumptions scattered throughout aren't appreciated, and I don't think
they're necessary to make your point at least to me. (Certainly if I
were a random person who just wanted to dump work on others, this
response would be potentially warranted and very effective at getting
said random person to just go away. But seeing as I'm actually
intending to do the work needed to make things happen, I don't *think*
you want me to just go away. :P) I've made a conscious effort to
look past those assumptions as much as possible and just get to the
technical details, and I am thankful for the insight you've provided.

Thanks again for taking a look at this!
Aaron

Post by Johannes Schauer Marin Rodrigues
Thanks!
cheers, josch

[Fay Stegerman]

* Johannes Schauer Marin Rodrigues <***@debian.org> [2024-11-06 02:28]:
[...]

Have one package diffoscope and one package diffoscope-full and you could even
have a package diffoscope-minimal and there you have user-selectable
granularity.

We already have two diffoscope packages for exactly this reason (I work on
diffoscope and only have -minimal installed myself):

$ apt-cache show diffoscope/sid | grep -A1 full
This is a dependency package that recommends the full set of external tools,
to support as many type of files as possible.

$ apt-cache show diffoscope-minimal/sid | grep -A2 partial
This -minimal package only recommends a partial set of the supported 3rd party
tools needed to produce file-format-specific comparisons, excluding those that
are considered too large or niche for general use.

- Fay

[Fay Stegerman]

Post by Fay Stegerman
[...]

Have one package diffoscope and one package diffoscope-full and you could even
have a package diffoscope-minimal and there you have user-selectable
granularity.

We already have two diffoscope packages for exactly this reason (I work on
$ apt-cache show diffoscope/sid | grep -A1 full
This is a dependency package that recommends the full set of external tools,
to support as many type of files as possible.
$ apt-cache show diffoscope-minimal/sid | grep -A2 partial
This -minimal package only recommends a partial set of the supported 3rd party
tools needed to produce file-format-specific comparisons, excluding those that
are considered too large or niche for general use.

IMO in the case of diffoscope it could make sense to have multiple tools
metapackages, like a diffoscope-tools-android etc., to both make it easier to
avoid those dependencies if you know you don't need them, but also to easily
install the dependencies for the file formats you do work with.

- Fay

[Richard Lewis]

Post by Fay Stegerman

Post by Fay Stegerman
[...]

Have one package diffoscope and one package diffoscope-full and you could even
have a package diffoscope-minimal and there you have user-selectable
granularity.

We already have two diffoscope packages for exactly this reason (I work on
$ apt-cache show diffoscope/sid | grep -A1 full
This is a dependency package that recommends the full set of external tools,
to support as many type of files as possible.
$ apt-cache show diffoscope-minimal/sid | grep -A2 partial
This -minimal package only recommends a partial set of the supported 3rd party
tools needed to produce file-format-specific comparisons, excluding those that
are considered too large or niche for general use.

IMO in the case of diffoscope it could make sense to have multiple tools
metapackages, like a diffoscope-tools-android etc., to both make it easier to
avoid those dependencies if you know you don't need them, but also to easily
install the dependencies for the file formats you do work with.

I think even diffoscope-minimal pulls in too much - all i wanted was a
better version of debdiff, but diffoscope-minimal recommends things like
openssl, openssh-client, r-base-core which seem well beyong "minimal" --
but you cant just purge all its recommends as some (like xz-utils) are
needed for other reasons.

[IOhannes m zmölnig]

Post by Aaron Rainbolt
* Add a "Weak-Depends" field to the list of binary dependency control
fields in the Debian Policy Manual section 7.2, with a definition
very similar to the existing definition for "Recommends".
* Change the definition of the "Recommends" field to match the way
the field is oftentimes used in the Debian archive.

This awfully reminds me of xkcd927 (even though it's not a good analogy).

Afaict, the problem is that we have 3 options to pick from, and it's hard for people to decide which is the "right one".
I do not see how adding a 4th option will make this decision any easier (esp. since that new option is so similar to an already existing one).

Just my 2¢


mfh.her.fsr
IOhannes

[Holger Levsen]

Post by IOhannes m zmölnig
Afaict, the problem is that we have 3 options to pick from, and it's hard for people to decide which is the "right one".
I do not see how adding a 4th option will make this decision any easier (esp. since that new option is so similar to an already existing one).

absolutly.

maybe the problem is also related that the original poster didn't know about
the diffoscope-minimal package because it's non obvious and somewhat hard
to find?

$ apt-cache search minimal|cut -d ' ' -f1|grep minimal$
cm-super-minimal
diffoscope-minimal
gdb-minimal
haskell-devscripts-minimal
keepassxc-minimal
kde-telepathy-minimal
python3-minimal
libpython3.12-minimal
python3.12-minimal
libpython3.13-minimal
python3.13-minimal
virtuoso-minimal

are there other similar metapackages?
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

„Faschisten hören niemals auf, Faschisten zu sein
Man diskutiert mit ihnen nicht, hat die Geschichte gezeigt“...

[Aaron Rainbolt]

On Wed, 6 Nov 2024 18:03:07 +0000

Post by Holger Levsen

Post by IOhannes m zmölnig
Afaict, the problem is that we have 3 options to pick from, and
it's hard for people to decide which is the "right one". I do not
see how adding a 4th option will make this decision any easier
(esp. since that new option is so similar to an already existing
one).

absolutly.

I have been thinking about it for a while and I am thinking that adding
a fourth field really is probably not the right way to go. Then again,
given that policy is clear about how Recommends ought to be used and
it's pretty clear that there are packages that just don't use it right,
I don't think an effort to "fix" the use of Recommends across Debian is
going to be terribly helpful because even if it succeeds, people are
probably going to make the same mistakes again. (It's not obvious that a
field called "Recommends" should only be used for not-quite-vital
dependencies, not recommendations in general. The very name of the
field begs for people to misuse it.)

Any suggestions for how to approach the problem as one of awareness
rather than one of technical limitations?

Post by Holger Levsen
maybe the problem is also related that the original poster didn't
know about the diffoscope-minimal package because it's non obvious
and somewhat hard to find?

My use of diffoscope was more to make a point in general about a
systemic problem (it was the most extreme example I could think of).
However, it is also true that I did not know about diffoscope-minimal,
and had I known about it I probably would have picked some other
package to illustrate the point. For instance, gwenview currently
recommends kamera. gwenview is an image viewer, kamera is a tool for
working with digital cameras. Now it is true that kamera enhances
gwenview's functionality by allowing it to see pictures on a digital
camera that is plugged into the system, but by no means is gwenview
useless or even substantially degraded from a functionality standpoint
when kamera is missing. It ought to be a Suggests according to Debian
policy, but it's obvious why it ended up being a Recommends because it
does enable additional functionality that doesn't work otherwise.

Aaron

Post by Holger Levsen
$ apt-cache search minimal|cut -d ' ' -f1|grep minimal$
cm-super-minimal
diffoscope-minimal
gdb-minimal
haskell-devscripts-minimal
keepassxc-minimal
kde-telepathy-minimal
python3-minimal
libpython3.12-minimal
python3.12-minimal
libpython3.13-minimal
python3.13-minimal
virtuoso-minimal
are there other similar metapackages?

[Soren Stoutner]

Post by Aaron Rainbolt
For instance, gwenview currently
recommends kamera. gwenview is an image viewer, kamera is a tool for
working with digital cameras. Now it is true that kamera enhances
gwenview's functionality by allowing it to see pictures on a digital
camera that is plugged into the system, but by no means is gwenview
useless or even substantially degraded from a functionality standpoint
when kamera is missing.

In my opinion, gwenview recomminding kamara is the correct behavior and inline
with policy.

If I install an app, Recommends should pull in everything that would make all
the buttons in the GUI work correctly. I shouldn’t have to manually install
anything else for them to work. Kamera should definitely be in Recommends for
gwenview (although not in depends).

If you don’t want that, set your system to not automatically install
recommended packages, and then you can manually install whatever you want to
get all the features of the app to work correctly. But please don’t mess up
Recommends working correctly for the rest of us.

[Aaron Rainbolt]

On Wed, 06 Nov 2024 14:21:30 -0700

Post by Soren Stoutner

Post by Aaron Rainbolt
For instance, gwenview currently
recommends kamera. gwenview is an image viewer, kamera is a tool for
working with digital cameras. Now it is true that kamera enhances
gwenview's functionality by allowing it to see pictures on a digital
camera that is plugged into the system, but by no means is gwenview
useless or even substantially degraded from a functionality
standpoint when kamera is missing.

In my opinion, gwenview recomminding kamara is the correct behavior
and inline with policy.
If I install an app, Recommends should pull in everything that would
make all the buttons in the GUI work correctly. I shouldn’t have to
manually install anything else for them to work. Kamera should
definitely be in Recommends for gwenview (although not in depends).
If you don’t want that, set your system to not automatically install
recommended packages, and then you can manually install whatever you
want to get all the features of the app to work correctly. But
please don’t mess up Recommends working correctly for the rest of us.

And this brings us back to the original idea of creating a Weak-Depends
field. From my viewpoint, policy states that Recommends is for
declaring a strong (heavy emphasis on "strong" here), but not absolute,
dependency. If the lack of kamera made it so that portions of
gwenview's user interface were visibly grayed out, or error messages
were displayed, then I would see it as a strong dependency since the
lack of it results in a substantial degredation of functionality. But
when kamera is missing, gwenview still works. Things that try to access
the `camera:` KIO slave won't work, but that's the extent of the issues
caused. KIO slaves are essentially plugins of sorts, so I see this as
an additional "nice-to-have" that isn't a dependency at all. This
isn't the only example either - I've had live image builds pull in
things that seemed (to me) to be completely "out of left field", like
random terminal emulators that I have neither interest in nor
willingness to keep in my image builds. (I don't know exactly which
package was the culprit there.)

The solution you mention is to not automatically install recommended
packages. But then you run into "fun" edge cases like system boot
failures[1], sudo or user-setup not being installed[2], and things like
that. When a packager needs to say "technically package A can function
without package B, but only if the user knows exactly what they're
doing", Recommends is the only way to express that, and if Recommends
is also being used to ship unnecessary terminal emulators, plugins for
little-used image viewer functionality, and the like, there's no good
solution except for manual fiddling. This is causing real problems in
at least one downstream derivative of Debian (Kicksecure, which I am
working with), which is why I'm hoping to find a good solution that I
can start implementing and sending patches for.

This isn't to disagree with you at all - I agree that gwenview shipping
kamera as a Recommends is a good thing. Like you say, "I shouldn't have
to manually install anything else for [the buttons in the GUI] to
work". That's a perfectly logical thing to use a field called
Recommends for. But if it's going to be used for that, it would be very
beneficial to identify packages that are recommended and important vs.
packages that are recommended but not that important. That's what I was
thinking Weak-Depends, or a solution similar to it, could do. In the
absence of that, demoting kamera to a Suggests would seem more
policy-compliant in my opinion, but then again that's just my opinion.

(Side note, I wonder if there's a way to implement Weak-Depends that
*doesn't* require modifying all of the tons of packages Johannes
mentioned. Maybe some way of annotating packages in Recommends as
"important" would permit a distinction to be made here in such a way
that most tools wouldn't need changes? Those that were updated would be
able to understand the distinction, those that weren't would continue
to treat Recommends the same way they do today. No idea if that's
feasible, just something that went through my head.)

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078792
If systemd-cryptsetup is missing on an encrypted system and one
installs dracut with --no-install-recommends, the system will be
rendered unbootable.
[2]: https://live-team.pages.debian.net/live-manual/html/live-manual/customizing-package-installation.en.html
Section 8.4.3

[Colin Watson]

Post by Aaron Rainbolt
(Side note, I wonder if there's a way to implement Weak-Depends that
*doesn't* require modifying all of the tons of packages Johannes
mentioned. Maybe some way of annotating packages in Recommends as
"important" would permit a distinction to be made here in such a way
that most tools wouldn't need changes? Those that were updated would be
able to understand the distinction, those that weren't would continue
to treat Recommends the same way they do today. No idea if that's
feasible, just something that went through my head.)

In some ways I think what we're missing is really a way to do the
equivalent of "extras" in Python packages
(https://peps.python.org/pep-0508/#extras): effectively groups of
additional dependencies to enable some kind of feature that you can opt
into if you need that feature, rather than having to pick from an
undifferentiated pile of Recommends, or do things like devscripts does
where you explain the Recommends you need for various tools in your
package description (and hope that they never change, because people
might not know that they need to keep up).

I don't think the proposed Weak-Depends particularly helps with that; it
adds another fine gradation along the axis of "how important is this
dependency", rather than considering the orthogonal axis of "what is
this dependency for".

In most cases you can get around this sort of thing using some extra
metapackages. This is usually workable, but since it involves a trip
through NEW people are reluctant to do it too much, and it contributes
to Packages bloat.

Still, I entirely agree with those who've said that adding new package
relationship fields is a _lot_ of work and should have a very high bar,
and the same goes for extending the syntax of existing fields. Not to
mention that we're kind of running out of convenient ASCII punctuation
characters.

[Aaron Rainbolt]

On Wed, 6 Nov 2024 22:55:43 +0000

Post by Colin Watson

Post by Aaron Rainbolt
(Side note, I wonder if there's a way to implement Weak-Depends that
*doesn't* require modifying all of the tons of packages Johannes
mentioned. Maybe some way of annotating packages in Recommends as
"important" would permit a distinction to be made here in such a way
that most tools wouldn't need changes? Those that were updated
would be able to understand the distinction, those that weren't
would continue to treat Recommends the same way they do today. No
idea if that's feasible, just something that went through my head.)

In some ways I think what we're missing is really a way to do the
equivalent of "extras" in Python packages
(https://peps.python.org/pep-0508/#extras): effectively groups of
additional dependencies to enable some kind of feature that you can
opt into if you need that feature, rather than having to pick from an
undifferentiated pile of Recommends, or do things like devscripts does
where you explain the Recommends you need for various tools in your
package description (and hope that they never change, because people
might not know that they need to keep up).
I don't think the proposed Weak-Depends particularly helps with that;
it adds another fine gradation along the axis of "how important is
this dependency", rather than considering the orthogonal axis of
"what is this dependency for".

That's a good point, and with a solution that focused on what
dependencies are for, one could prevent severe issues by marking a
dependency as "basic", i.e. without this, basic functionality breaks or
is very likely to break. That could be used for things like
dracut's dependency on systemd-cryptsetup or live-config's dependencies
on sudo and user-setup. Then the user could choose the extra
functionality they wanted on a package-by-package basis.

There are two kinds of categorization here that should be taken into
account - there's the way a package perceives its dependencies, and the
way a package perceives itself. For instance, diffoscope may perceive
mono-runtime primarily as a tool for disassembling .NET applications
into CIL bytecode, while other packages may perceive it primarily as a
runtime environment. The way in which a package perceives itself is
already handled in Debian (to some degree at least) by the sections
mechanism and the priority field, while it sounds like you're talking
specifically about how packages perceive other packages, for instance
diffoscope could declare its dependency on mono-runtime as being in a
group of recommends called "code-disassemblers" or whatever. Is that
right?

Post by Colin Watson
In most cases you can get around this sort of thing using some extra
metapackages. This is usually workable, but since it involves a trip
through NEW people are reluctant to do it too much, and it contributes
to Packages bloat.
Still, I entirely agree with those who've said that adding new package
relationship fields is a _lot_ of work and should have a very high
bar, and the same goes for extending the syntax of existing fields.
Not to mention that we're kind of running out of convenient ASCII
punctuation characters.

Agreed. Still though, if a good theoretical solution is found here, I'm
willing to at least try implementing it even if it does end up being a
lot of work to bring it to fruition.

Aaron

[Sune Vuorela]

Post by Colin Watson
In some ways I think what we're missing is really a way to do the
equivalent of "extras" in Python packages
(https://peps.python.org/pep-0508/#extras): effectively groups of
additional dependencies to enable some kind of feature that you can opt
into if you need that feature, rather than having to pick from an

And conditional dependencies/recommends. Maybe they're kind of the same:

Package: foo
Recommends: foo-l10n-de[language-de]

Package: libQtGui
Depends: libQtWayland[gui-thingie-wayland], libQtX11[gui-thingie-x11]

Package: php
Depends: php-apache2-glue[apache2-is-installed],
php-nginx-glue[nginx-is-installed]

But I think this is kind of just dreaming at this point.

/Sune

[nick black]

Post by Colin Watson
(https://peps.python.org/pep-0508/#extras): effectively groups of
additional dependencies to enable some kind of feature that you can opt
into if you need that feature, rather than having to pick from an
undifferentiated pile of Recommends, or do things like devscripts does

the "undifferentiated" feels like it's doing some lifting here.
arch's yay (and presumably other tools in the pacman family)
shows a short justification for each optdepends[0] entry (when
such information is provided). it would require not just control
file changes but also UI work, of course.

--nick

[0] https://man.archlinux.org/man/PKGBUILD.5

[Soren Stoutner]

Post by Aaron Rainbolt
And this brings us back to the original idea of creating a Weak-Depends
field. From my viewpoint, policy states that Recommends is for
declaring a strong (heavy emphasis on "strong" here), but not absolute,
dependency.

After reading over the policy on the subject, I do agree that the current
policy is a little vague as to what is intended.

"Recommends

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.”

https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends

What constitutes a strong dependency, or what constitutes packages being found
together in all but unusual installations can be interpreted differently by
different people. I would be in favor of rewording the policy to be more
expressly inline with how Recommends is currently interpreted and used by the
majority of maintainers and users, which is that all packages that are
required for expected functionality should be included in Recommends, even if
a feature is only used by a subset of users. Suggests should be for packages
that enhance some aspect of the program, but which most users would either not
expect to be installed automatically or are so large that a user should make
an explicit decision to install them.

There probably are some packages that have items in Recommends that should
actually be in Suggests. I once received a bug report from a user asking me
to move a package from Recommends to Suggests, which suggestion I agreed with
and was grateful for receiving. But personally, I would find an additional
category unnecessary and even confusing, especially because users already have
the option to not auto-install recommended packages if they really don’t want
them (which usually comes down to space-saving concerns, especially on
embedded systems).

[Aaron Rainbolt]

On Wed, 06 Nov 2024 15:59:22 -0700

Post by Soren Stoutner

Post by Aaron Rainbolt
And this brings us back to the original idea of creating a
Weak-Depends field. From my viewpoint, policy states that
Recommends is for declaring a strong (heavy emphasis on "strong"
here), but not absolute, dependency.

After reading over the policy on the subject, I do agree that the
current policy is a little vague as to what is intended.
"Recommends
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.”
https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends
What constitutes a strong dependency, or what constitutes packages
being found together in all but unusual installations can be
interpreted differently by different people. I would be in favor of
rewording the policy to be more expressly inline with how Recommends
is currently interpreted and used by the majority of maintainers and
users, which is that all packages that are required for expected
functionality should be included in Recommends, even if a feature is
only used by a subset of users. Suggests should be for packages that
enhance some aspect of the program, but which most users would either
not expect to be installed automatically or are so large that a user
should make an explicit decision to install them.

I suppose I'd argue that kamera only enhances some aspect of gwenview,
but meh, neither of us are really "right" since this is a matter of
opinion. It's probably better to look at the practical problems I and
the developers of Kicksecure are running into that inspired this thread
initially.

Kicksecure is a security-focused Debian derivative that is intended to
be essentially Debian with every reasonable security hardening feature
in existence enabled out of the box. Kicksecure is also used as the
base of Whonix, which is intended to provide anonymity features that
can be used within virtual machines. We have a number of our own
packages that we ship on our images, and we have a number of
metapackages that depend on both our own packages and many packages
from the Debian repositories.

Some of the packages Kicksecure's metapackages depend on are hard
dependencies, i.e. if they're removed, the system should be considered
broken. On the other hand, many of our packages are ones that we
believe should be present on most installations, but that a user may
legitimately want rid of. This probably sounds like a good fit for the
Depends and Recommends fields of debian/control, since it is, except
for one major issue.

When we build the Kicksecure images with recommends enabled, they end
up with *a lot* of gunk that we don't want. Some packages that end up
installed cause actual problems (user can't log in, Debian artwork
ends up appearing where it shouldn't, default terminal emulator is
hijacked by something called ZuTTY, etc.), other packages simply
increase the size of the ISO for no good reason. This is the result of
people using the Recommends field the way you're suggesting the policy
be changed to explicitly allow.

At this point, we have two options. We can either explicitly remove all
of the extra packages that get installed, or we can skip installing
recommends at all. Both of these come with their own severe
disadvantages. If we manually uninstall everything we don't need, that
means we have to maintain a list of packages that get incorrectly
installed, and keep it up-to-date as package dependencies in the
archive change. On top of that, if a package happens to not uninstall
cleanly, or it otherwise causes problems when installed or uninstalled,
we'd have to figure out how to manually fix that, or avoid letting that
particular package ever get installed in the first place via held
packages or a similar mechanism. This is a rather large amount of work,
and it's not easy to maintain.

The other option is to skip installing recommends. The reason that
doesn't work well is because if we do that, we can't use recommends in
our metapackages at all - anything we specify as a recommends in the
metapackages won't end up installed. To work around that, we have to
use depends for everything, and to do *that*, we have to basically
reimplement the whole darn recommended packages mechanism in
metapackages. This results in the metapackages setup that we have
today, which can be seen at [1]. There's some "dependencies" packages,
some "recommends" packages, a complex network between the packages to
make things work right, and a smattering of dummy dependencies to allow
users to override certain depends. Our current metapackages scheme has
some rather inconsistent naming and could use a lot of improvement, but
even under ideal conditions (like what I've proposed for Kicksecure in
[2]), this is a lot of ugly hacks that reimplement existing apt
features without using those features just to get around problematic
recommends in Debian's packages. And this is likely *easier* to
maintain than manually uninstalling everything we don't want.

If Debian's packages treated Recommends as "dependencies that are
technically removable but you probably shouldn't remove them" for
packages other than metapackages, this wouldn't be an issue. That's not
possible here though.

So, that's the issue we're having, and the solutions I'm pursuing
(using Recommends differently, adding a Weak-Depends field, or
implementing something like Python's extras like Colin was mentioning)
are things I think would fix the problem for us and others. I'm
definitely open to suggestions for other ways we could avoid these
problems though.

Aaron

[1]: https://github.com/Kicksecure/kicksecure-meta-packages/blob/master/debian/control
[2]: https://gist.github.com/ArrayBolt3/1312aa401d0b7ade970210b3f526f9e8#file-kicksecure-metapackage-audit-L54

[Soren Stoutner]

Post by Aaron Rainbolt
At this point, we have two options. We can either explicitly remove all
of the extra packages that get installed, or we can skip installing
recommends at all. Both of these come with their own severe
disadvantages. If we manually uninstall everything we don't need, that
means we have to maintain a list of packages that get incorrectly
installed, and keep it up-to-date as package dependencies in the
archive change. On top of that, if a package happens to not uninstall
cleanly, or it otherwise causes problems when installed or uninstalled,
we'd have to figure out how to manually fix that, or avoid letting that
particular package ever get installed in the first place via held
packages or a similar mechanism. This is a rather large amount of work,
and it's not easy to maintain.
The other option is to skip installing recommends. The reason that
doesn't work well is because if we do that, we can't use recommends in
our metapackages at all - anything we specify as a recommends in the
metapackages won't end up installed. To work around that, we have to
use depends for everything, and to do *that*, we have to basically
reimplement the whole darn recommended packages mechanism in
metapackages. This results in the metapackages setup that we have
today, which can be seen at [1]. There's some "dependencies" packages,
some "recommends" packages, a complex network between the packages to
make things work right, and a smattering of dummy dependencies to allow
users to override certain depends. Our current metapackages scheme has
some rather inconsistent naming and could use a lot of improvement, but
even under ideal conditions (like what I've proposed for Kicksecure in
[2]), this is a lot of ugly hacks that reimplement existing apt
features without using those features just to get around problematic
recommends in Debian's packages. And this is likely *easier* to
maintain than manually uninstalling everything we don't want.

This sounds like exactly the type of work I would expect a derivative
distribution to do. If I were in your shoes, I would probably do something
like rebuild all packages for my derivative and host them in my own
repositories, like Ubuntu does. During that rebuild process, I would use some
sort of patch process to alter the Recommends fields to suite the needs of my
particular derivative distribution. It would take time to setup and maintain
such patches, but that is exactly the type of effort that is required to run a
distribution.

Post by Aaron Rainbolt
So, that's the issue we're having, and the solutions I'm pursuing
(using Recommends differently, adding a Weak-Depends field, or
implementing something like Python's extras like Colin was mentioning)
are things I think would fix the problem for us and others. I'm
definitely open to suggestions for other ways we could avoid these
problems though.

This really is the type of problem that needs to be solved inside of your
derivative distribution, not in Debian itself, especially in ways that makes
Debian worse for its own users or requires a bunch of extra work for Debian's
maintainers (like figuring out how to sort all of the Recommends into these new
fields/extras options, which different derivatives/users would have distinct
opinions about where they should go and would require a lot of time from
Debian developers to get each package to a state that would make all potential
consumers of the package happy).

I am sympathetic to the problems you are having. And I wish you all the best
in creating a distribution that meets the needs of your users. Like I said
earlier, if there are specific packages that actually have the wrong
Recommends, I’m sure the package maintainers would welcome a bug report
explaining why a package should be moved to Suggests. But in most cases, what
is currently in Recommends is what is in the best interests of Debian users.
Unless you can point to a systematic problem with Recommends in Debian (which
the examples you have presented so far have not shown), I don’t think upstream
Debian is the place to fix the particular needs of your derivative
distribution.

[Aaron Rainbolt]

On Wed, 06 Nov 2024 21:41:43 -0700

Post by Soren Stoutner

Post by Aaron Rainbolt
At this point, we have two options. We can either explicitly remove
all of the extra packages that get installed, or we can skip
installing recommends at all. Both of these come with their own
severe disadvantages. If we manually uninstall everything we don't
need, that means we have to maintain a list of packages that get
incorrectly installed, and keep it up-to-date as package
dependencies in the archive change. On top of that, if a package
happens to not uninstall cleanly, or it otherwise causes problems
when installed or uninstalled, we'd have to figure out how to
manually fix that, or avoid letting that particular package ever
get installed in the first place via held packages or a similar
mechanism. This is a rather large amount of work, and it's not easy
to maintain.
The other option is to skip installing recommends. The reason that
doesn't work well is because if we do that, we can't use recommends
in our metapackages at all - anything we specify as a recommends in
the metapackages won't end up installed. To work around that, we
have to use depends for everything, and to do *that*, we have to
basically reimplement the whole darn recommended packages mechanism
in metapackages. This results in the metapackages setup that we have
today, which can be seen at [1]. There's some "dependencies"
packages, some "recommends" packages, a complex network between the
packages to make things work right, and a smattering of dummy
dependencies to allow users to override certain depends. Our
current metapackages scheme has some rather inconsistent naming and
could use a lot of improvement, but even under ideal conditions
(like what I've proposed for Kicksecure in [2]), this is a lot of
ugly hacks that reimplement existing apt features without using
those features just to get around problematic recommends in
Debian's packages. And this is likely *easier* to maintain than
manually uninstalling everything we don't want.

This sounds like exactly the type of work I would expect a derivative
distribution to do. If I were in your shoes, I would probably do
something like rebuild all packages for my derivative and host them
in my own repositories, like Ubuntu does. During that rebuild
process, I would use some sort of patch process to alter the
Recommends fields to suite the needs of my particular derivative
distribution. It would take time to setup and maintain such patches,
but that is exactly the type of effort that is required to run a
distribution.

I'm not sure why this would be a reasonable solution here. Kicksecure
already has a solution that is working. We dislike it, and I'd like for
something better to exist, but our metapackage tricks work for the time
being.

To be clear, I am not just doing this because I have a job to do and
this is part of it. I'm doing this because I truly believe that
Debian's current "recommended bloat" issues are a problem within Debian
itself and are worth my time and effort to solve. With that in mind,
bringing into the picture what a derivative should or shouldn't do
isn't really relevant to the discussion at hand. Much like the
diffoscope example, Kicksecure's issues were intended to be an example,
not a definition of an end goal.

Post by Soren Stoutner

Post by Aaron Rainbolt
So, that's the issue we're having, and the solutions I'm pursuing
(using Recommends differently, adding a Weak-Depends field, or
implementing something like Python's extras like Colin was
mentioning) are things I think would fix the problem for us and
others. I'm definitely open to suggestions for other ways we could
avoid these problems though.

This really is the type of problem that needs to be solved inside of
your derivative distribution, not in Debian itself, especially in
ways that makes Debian worse for its own users or requires a bunch of
extra work for Debian's maintainers (like figuring out how to sort
all of the Recommends into these new fields/extras options, which
different derivatives/users would have distinct opinions about where
they should go and would require a lot of time from Debian developers
to get each package to a state that would make all potential
consumers of the package happy).

There's no reason this exact issue couldn't happen in Debian itself.
Any metapackage system that encourages its users to use
--no-install-recommends to avoid installation of unnecessary packages
is going to run into the exact same problem, whether inside of Debian
or outside of it. For that matter, any Debian user who uses
--no-install-recommends with a metapackage that uses Recommends is
going to run into the same kind of problem.

Post by Soren Stoutner
I am sympathetic to the problems you are having. And I wish you all
the best in creating a distribution that meets the needs of your
users. Like I said earlier, if there are specific packages that
actually have the wrong Recommends, I’m sure the package maintainers
would welcome a bug report explaining why a package should be moved
to Suggests. But in most cases, what is currently in Recommends is
what is in the best interests of Debian users. Unless you can point
to a systematic problem with Recommends in Debian (which the examples
you have presented so far have not shown), I don’t think upstream
Debian is the place to fix the particular needs of your derivative
distribution.

Again, this isn't a problem limited to a derivative distribution. I
respect that your opinion of how Recommends should work differs from
mine. That doesn't change the policy though, and it doesn't change that
neglecting or changing the policy's rules in this area will cause and
is causing problems to some of Debian's users. Ultimately I don't care
exactly how those problems are solved, I just want to solve them.

In case it's helpful to know, I do *not* want to make Debian worse. A
solution that makes Debian worse is not a solution at all since the
primary goal of my endeavor here is to make Debian better for everyone.
The issues you've mentioned with some of my suggestions are real, and
you may notice I actually agree with you about the need for a less
strict Recommends. It's important to me though that if Recommends is to
become formally less strict, that something step in to replace it and
act as a strict optional dependency specifier. Colin's idea seems to be
the most promising in this area so far, and I'll probably try to
implement a prototype of it once the ideas have some time to develop a
bit more.

Aaron

[Soren Stoutner]

Post by Aaron Rainbolt
Again, this isn't a problem limited to a derivative distribution. I
respect that your opinion of how Recommends should work differs from
mine. That doesn't change the policy though, and it doesn't change that
neglecting or changing the policy's rules in this area will cause and
is causing problems to some of Debian's users. Ultimately I don't care
exactly how those problems are solved, I just want to solve them.

Let me try to explain what I see as the core of the problem.

First, some background on the three existing categories.

1. Depends: These are the packages necessary to install and run the basic functionality of
the package.

2. Recommends: These are the packages required to enable all the features of the
package.

3. Suggests: These are packages that enhance the functionality of the package.

Enabling a feature in the package is a "strong dependency”, which is what is meant by the
policy. I agree that it could be worded in such a way as to be more clear to some people,
particularly if they are not familiar with Debian or for whom English is not their primary
language, but I want to be clear that the way I have defined Recommends above is exactly
what the current policy envisions (at least I believe that is the understanding of the
majority of the Debian community).

When a user installs a package and all the Recommends, they should be able to expect
that all of the features of the package should just work. They should not have to go
hunting down some other package to install to enable one of the features of the package,
even if that feature is less commonly used.

Some packages are clearly in Depends, Recommends, or Suggests. Others might be right
on the line between two of the categories. In these cases, a maintainer has to make a
judgement call. If a user thinks they have got it wrong, they are welcome to submit a bug
report explaining why they think it should be in the other category.

Some upstream projects are complex enough that the above three categories don’t fully
capture the needs of users. In those cases, meta-packages can accommodate those
needs, as has already been discussed (which is analogous to Python "extras"). If a user
believe there is a compelling case to be made for an additional meta-package, they should
feel free to file a bug report and explain the merits of their request.

With all of that said as background, the reason why I am opposed to what you are
requesting is that it boils down to: "Please create a package category that only installs the
important features instead of all the ones I don’t use”. This category would be somewhere
in between Depends (the packages necessary to run the basic functionality) and
Recommends (the packages necessary to run all the functionality).

What I don’t like about this idea is it requires the package maintainer to be a mind reader.
Specifically, they need to read *your* mind, because every single user has a different list
of what the “important” functionality is. What you or your distribution considers important
the next user or distribution would say, “I never use that, take it out. But I need this other
thing.”

Maintainers would end up having to create multiple variations of each package to make
everyone happy. It is unsustainable. If you, as a user, want something between the basic
functionality and all the functionality, please just install the basic functionality (Depends)
and then add the extra functionality that is important to you. Don’t ask the package
maintainer to read you mind and guess at what that will be.

[gregor herrmann]

Post by Soren Stoutner
Some packages are clearly in Depends, Recommends, or Suggests. Others might be right
on the line between two of the categories. In these cases, a maintainer has to make a
judgement call. If a user thinks they have got it wrong, they are welcome to submit a bug
report explaining why they think it should be in the other category.

This paragraph sums up my thoughts on this topic pretty well, thanks.

The distinction between Depends, Recommends or Suggests is not a
true/false thing; this is not a question of mathematics or science
but always a judgement call. Adding another category won't solve
anything IMO but only extend the sometimes blurry area.

Clarifying policy may or may not help, in the end there will always
be uncertainties, clarifications, bug reports, and the common effort
to find the best solution for most users.


Cheers,
gregor

[Philipp Kern]

Post by gregor herrmann
The distinction between Depends, Recommends or Suggests is not a
true/false thing; this is not a question of mathematics or science
but always a judgement call. Adding another category won't solve
anything IMO but only extend the sometimes blurry area.
Clarifying policy may or may not help, in the end there will always
be uncertainties, clarifications, bug reports, and the common effort
to find the best solution for most users.

And, IMO more importantly, there is a question of why this problem needs
solving. What are the underlying pain points people have. If a package
that is pulled in by a Recommends breaks your local configuration (the
example with the terminal emulator getting hijacked), that is indeed a
problem - and that should be fixed regardless. Otherwise it is maybe a
bit wasteful in terms of bandwidth (initial download and updates) and
disk space - but installing yet another package should not otherwise
hurt the user. In general the requirements imposed here are not
outrageous and maybe in the rare cases where they are bug reports might
be useful.

If you are building a derivative and are concerned about recommends
pulling in "random" things: Sure, but arguably you would want to control
your dependencies more strongly anyway - be it for support load, or
other constraints. Having an allowlist of packages that you compare your
package set against that you review for changes might help. And then you
just go and prune what isn't on the list. Or maybe have a metapackage
that conflicts against unwanted software.

For others it might be about more easily surfacing individual feature
sets to the user (like tasksel, but for software groups) where
metapackages might be a bit too messy. But then that's a different ask
from a weak-depends, as well.

Kind regards
Philipp Kern

[Theodore Ts'o]

Post by Soren Stoutner

Post by Aaron Rainbolt
Again, this isn't a problem limited to a derivative distribution. I
respect that your opinion of how Recommends should work differs from
mine. That doesn't change the policy though, and it doesn't change that
neglecting or changing the policy's rules in this area will cause and
is causing problems to some of Debian's users. Ultimately I don't care
exactly how those problems are solved, I just want to solve them.

Let me try to explain what I see as the core of the problem.
First, some background on the three existing categories.
1. Depends: These are the packages necessary to install and run the basic functionality of
the package.
2. Recommends: These are the packages required to enable all the features of the
package.
3. Suggests: These are packages that enhance the functionality of the package.

So if we have consensus that these definitions of the categories is
correct, then there shouldn't be any contrversy of whether gwenview is
"wrong"in recommending kamera, which Aaron was objecting to. After
all, there is a button in gwenview that would activate kamera. If
kamera is not installed, then no matter how many time the user mashes
the "kamera" button, Nothing Will Happen. So clearly, thats a
"feature" of gwenview, and kamera should _absolutely_ be a Recommends.
No?

But let's take a step backwards about why there seems to be so much
passion about this question. Especially when I really don't care all
that much. Part of this is because as far as I'm concerned, my time
is valuble, and storage is _cheap_ so I always configure a huge amount
of storage on my desktops. For example, my root file system is 824
GiB --- and Kamera is 1 MiB. So as far as I'm concerned, the amount
of time that I've spent reading this e-mail thread is far more
expensive that the storage cost of Kamera. :-)

So why do we care? If someone is installing in a very
storage-constrained environment --- say, the are creating some
appliance image to be hosted on a VM, or Docker, or a Raspberry Pi ---
then just configure apt to ignore all of the recommends. Someone who
is trying to configure the appliance may need to do a bit more work to
figure out what package are *really* needed, but if they are really so
concerned about minimizing every single byte, then that's probably the
right answer.

And these days, with the size of most desktop systems, maybe we should
be optimizing for user convenience, and for that use case, just
installing all of the Recommends packages is again, probably the best
choice in terms of making life easy for users, at the minor cost of
paying a bit more for storage. (Reminder: 1TiB of SSD can be as cheap
as $50 USD --- and if you want to super-duper expensive, gold-plated
SSD you have to spend $100 USD. Horrors!)

So what we seem to be trying to optimize for is this middle ground
where storage is not super-duper constrained, where the user will want
to very carefully consider every single package to decide whether or
not each package should be installed --- and yet storage is *just*
cheap enough that you want to have "the right thing" to happen. The
only problem is that everybody's opinion is going to be different
about what "the right thing would actually be". And until we can have
some kind of AI were you can tell the system what exactly you plan to
use diffoscope for in human language, and have it automatically decide
what packages you need or not, I don't think this problem is really
soluble.

Fortunately, I also don't think it's all that important that we solve
it. Personally, I think the current set of knobs and defaults are the
right one.

Regards,

- Ted

[Aaron Rainbolt]

On Thu, 7 Nov 2024 22:29:07 -0500

Post by Theodore Ts'o

Post by Soren Stoutner

Post by Aaron Rainbolt
Again, this isn't a problem limited to a derivative distribution.
I respect that your opinion of how Recommends should work differs
from mine. That doesn't change the policy though, and it doesn't
change that neglecting or changing the policy's rules in this
area will cause and is causing problems to some of Debian's
users. Ultimately I don't care exactly how those problems are
solved, I just want to solve them.

Let me try to explain what I see as the core of the problem.
First, some background on the three existing categories.
1. Depends: These are the packages necessary to install and run
the basic functionality of the package.
2. Recommends: These are the packages required to enable all the
features of the package.
3. Suggests: These are packages that enhance the functionality of the package.

So if we have consensus that these definitions of the categories is
correct, then there shouldn't be any contrversy of whether gwenview is
"wrong"in recommending kamera, which Aaron was objecting to. After
all, there is a button in gwenview that would activate kamera. If
kamera is not installed, then no matter how many time the user mashes
the "kamera" button, Nothing Will Happen. So clearly, thats a
"feature" of gwenview, and kamera should _absolutely_ be a Recommends.
No?
But let's take a step backwards about why there seems to be so much
passion about this question. Especially when I really don't care all
that much. Part of this is because as far as I'm concerned, my time
is valuble, and storage is _cheap_ so I always configure a huge amount
of storage on my desktops. For example, my root file system is 824
GiB --- and Kamera is 1 MiB. So as far as I'm concerned, the amount
of time that I've spent reading this e-mail thread is far more
expensive that the storage cost of Kamera. :-)
So why do we care? If someone is installing in a very
storage-constrained environment --- say, the are creating some
appliance image to be hosted on a VM, or Docker, or a Raspberry Pi ---
then just configure apt to ignore all of the recommends. Someone who
is trying to configure the appliance may need to do a bit more work to
figure out what package are *really* needed, but if they are really so
concerned about minimizing every single byte, then that's probably the
right answer.
And these days, with the size of most desktop systems, maybe we should
be optimizing for user convenience, and for that use case, just
installing all of the Recommends packages is again, probably the best
choice in terms of making life easy for users, at the minor cost of
paying a bit more for storage. (Reminder: 1TiB of SSD can be as cheap
as $50 USD --- and if you want to super-duper expensive, gold-plated
SSD you have to spend $100 USD. Horrors!)
So what we seem to be trying to optimize for is this middle ground
where storage is not super-duper constrained, where the user will want
to very carefully consider every single package to decide whether or
not each package should be installed --- and yet storage is *just*
cheap enough that you want to have "the right thing" to happen. The
only problem is that everybody's opinion is going to be different
about what "the right thing would actually be". And until we can have
some kind of AI were you can tell the system what exactly you plan to
use diffoscope for in human language, and have it automatically decide
what packages you need or not, I don't think this problem is really
soluble.
Fortunately, I also don't think it's all that important that we solve
it. Personally, I think the current set of knobs and defaults are the
right one.

The problem isn't mainly storage actually, there are reasons beyond
storage why one may wish to keep their package set minimal. I'm
tempted to give examples here but almost every example I give ends up
being a point of contention, so I think I'll just leave it there. :P
At least from my standpoint, and probably from the standpoint of
several others, Recommends oftentimes pulls in things that are
problematic for whatever reason (causes crashes, introduces wrong
artwork, etc.). In the opinions of many other developers, it appears
that not all of these "problematic" things can be moved out of
Recommends reasonably (and frankly I agree). There are some controls
in apt and Debian for dealing with this, but they are *not* sufficient
to reasonably avoid issues in all situations (unless reimplementing the
Recommends field using a metapackage network is considered reasonable).

Elsewhere, someone had the idea of restricting which packages had
their recommends installed, giving finer-grained control than
--no-install-recommends without requiring a whole lot of work. Soren
mentioned they didn't have a particular problem with this kind of
solution, and so far I think it's the most promising one at the moment.
Hopefully that will let everyone have what they want - Recommends will
remain used like they are now, Debian packaging will be unaffected, and
users will be able to concisely specify which recommends they want to
install and which ones they don't. It won't fix situations where a
recommended package is legitimately wrong and should be demoted or
moved, but even in those situations workarounds exist, and bugs can be
filed. I think that's probably what will work best.

Thanks for the good discussion on all of this!
Aaron

Post by Theodore Ts'o
Regards,
- Ted

[gregor herrmann]

Post by Aaron Rainbolt
Then again,
given that policy is clear about how Recommends ought to be used and
it's pretty clear that there are packages that just don't use it right,

I'm sorry but I have to disagree here; it's "pretty clear" for you
but I believe that there is no such thing as an absolute
(nature|god|policy)-given truth; some people may think that the usage
of Recommends is more or less correct, others my think that it's more
or less incorrect but all we have is a hopefully respectful way to
find a temporary consensus.

(Why do I write such philsophical mails? Because I'm a bit concerned
how often people confuse their perception with some kind of
"reality"; and I had the hunch that this thread might also partially
take this direction 
)


Cheers,
gregor

[Bill Allombert]

Post by Aaron Rainbolt
Hello, and thanks for your time.
I've been a Debian user and contributor for a while, and have noticed a
rather frustrating issue that I'm interested in potentially
contributing code to fix. The issue is what I call "Recommended bloat",
which in short is what happens when you install a package with all of
its recommended packages, and end up with a whole lot of stuff installed
that you don't want and that the package you actually wanted probably
didn't even need.

A proposal I made was an option for apt to handle Recommends non
recursively.
That is if A Recommends B and B Recommends C,
apt-get install A --no-transitive-recommends
would install B but not C.

Cheers,
Bill.

[Roger Lynn]

Post by Bill Allombert

Post by Aaron Rainbolt
Hello, and thanks for your time.
I've been a Debian user and contributor for a while, and have noticed a
rather frustrating issue that I'm interested in potentially
contributing code to fix. The issue is what I call "Recommended bloat",
which in short is what happens when you install a package with all of
its recommended packages, and end up with a whole lot of stuff installed
that you don't want and that the package you actually wanted probably
didn't even need.

A proposal I made was an option for apt to handle Recommends non
recursively.
That is if A Recommends B and B Recommends C,
apt-get install A --no-transitive-recommends
would install B but not C.

This, please!

As a user, when I choose to install a package, I am likely to have a
reasonable idea of what that package's recommendations do and whether I need
them. However, for transitive recommendations, it is unlikely that I will
know whether I need those packages. If they in turn have lots of further
dependencies then I will probably not install them and take the risk of
unwanted breakage to my system. If the top level package that I originally
did want needs those transitive recommendations it should recommend them
itself, rather than relying on recommendations further down the dependency
chain.

It would also be helpful if more package descriptions could explain why
recommended and suggested packages are needed or helpful and what
functionality they provide that would be lost if they were not installed.
(Many already do this.)

Thanks,

Roger

PS. I use aptitude, so I can interactively browse through the lists of
recommendations, but it's still hard work and it can be a long list of very
obscure packages. Do any of the GUI package managers show a graphical
dependency tree? That might be really helpful to understand the package
relationships and visualise the consequences of various actions.

PPS. And the moon on a stick too, please!

[Soren Stoutner]

Post by Roger Lynn

Post by Bill Allombert

Post by Aaron Rainbolt
Hello, and thanks for your time.
I've been a Debian user and contributor for a while, and have noticed a
rather frustrating issue that I'm interested in potentially
contributing code to fix. The issue is what I call "Recommended bloat",
which in short is what happens when you install a package with all of
its recommended packages, and end up with a whole lot of stuff installed
that you don't want and that the package you actually wanted probably
didn't even need.

A proposal I made was an option for apt to handle Recommends non
recursively.
That is if A Recommends B and B Recommends C,
apt-get install A --no-transitive-recommends
would install B but not C.

This, please!

I should have noted previously (I apologize for not doing so) that the
objections I have voiced to some of the proposals do not apply to this
proposal. If having this type of option would be helpful (and if the
maintainers of apt don't have objections to someone implementing this) than I
also do have any objections as it doesn't cause any extra work for package
maintainers in general and it doesn't change the way Recommends works for
people who chose not to use this argument.

[Aaron Rainbolt]

On Thu, 7 Nov 2024 19:53:27 +0000

Post by Roger Lynn

Post by Bill Allombert

Post by Aaron Rainbolt
Hello, and thanks for your time.
I've been a Debian user and contributor for a while, and have
noticed a rather frustrating issue that I'm interested in
potentially contributing code to fix. The issue is what I call
"Recommended bloat", which in short is what happens when you
install a package with all of its recommended packages, and end up
with a whole lot of stuff installed that you don't want and that
the package you actually wanted probably didn't even need.

A proposal I made was an option for apt to handle Recommends non
recursively.
That is if A Recommends B and B Recommends C,
apt-get install A --no-transitive-recommends
would install B but not C.

This, please!
As a user, when I choose to install a package, I am likely to have a
reasonable idea of what that package's recommendations do and whether
I need them. However, for transitive recommendations, it is unlikely
that I will know whether I need those packages. If they in turn have
lots of further dependencies then I will probably not install them
and take the risk of unwanted breakage to my system. If the top level
package that I originally did want needs those transitive
recommendations it should recommend them itself, rather than relying
on recommendations further down the dependency chain.

One issue with this is that it doesn't really work if you're dealing
with metapackages that in turn reference other metapackages. You end up
with the "lower" metapackages installed but all of their recommends
missing. Making it possible to tune the number of "levels" apt digs
would make something like this more useful, but it's still possible for
there to be a "lopsided" network of metapackages, where installing
recommends to level N results in a metapackage's recommends being
omitted, but installing recommends to level N+1 results in a
non-metapackage's recommends being installed.

However, this isn't that hard to rectify - rather than specifying the
depth at which apt should stop installing recommends, one can specify
the packages in the dependency tree from which apt should install
recommends from. I.e., to replicate --no-transitive-recommends, one
would do
`sudo apt install package --only-install-recommends-from=package`
(please someone pick a better name for this switch). If you're
installing a complex metapackage network, you can just specify all the
metapackages you want to allow recommends from, i.e.
`sudo apt install metapackage --only-install-recommends-from=metapackage,submetapackage1,...`
This could then be used in combination with per-install package
blacklisting (i.e., `sudo apt install gwenview+ kamera-`) to control
recommends very easily and without much effort. As for Kicksecure, it
would solve the problems we're running into perfectly, since we'd be
able to use recommends in our metapackages and get the advantages of
skipping them for normal packages. No changes needed to Debian policy.
No changes needed to debian/control. Just modifying apt is enough to
begin with, and might even be enough in the long run. This wouldn't fix
the issue of packages having too much in their Recommends, but that can
be handled with bug reports.

Aaron

Post by Roger Lynn
It would also be helpful if more package descriptions could explain
why recommended and suggested packages are needed or helpful and what
functionality they provide that would be lost if they were not
installed. (Many already do this.)
Thanks,
Roger
PS. I use aptitude, so I can interactively browse through the lists of
recommendations, but it's still hard work and it can be a long list
of very obscure packages. Do any of the GUI package managers show a
graphical dependency tree? That might be really helpful to understand
the package relationships and visualise the consequences of various
actions.
PPS. And the moon on a stick too, please!

[Fay Stegerman]

* Aaron Rainbolt <***@gmail.com> [2024-11-08 00:21]:
[...]

Post by Aaron Rainbolt
However, this isn't that hard to rectify - rather than specifying the
depth at which apt should stop installing recommends, one can specify
the packages in the dependency tree from which apt should install
recommends from. I.e., to replicate --no-transitive-recommends, one
would do
`sudo apt install package --only-install-recommends-from=package`
(please someone pick a better name for this switch). If you're
installing a complex metapackage network, you can just specify all the
metapackages you want to allow recommends from, i.e.
`sudo apt install metapackage --only-install-recommends-from=metapackage,submetapackage1,...`

[...]

I personally would consider a "apt install-recs", analogous to "apt build-dep",
quite useful. That would require multiple steps instead of a single command,
but allow installing the recommends for a specific package at any later time,
which is also useful when they have changed over time or you change your mind
about installing them.

- Fay

[Marc Haber]

Post by Fay Stegerman
I personally would consider a "apt install-recs", analogous to "apt build-dep",
quite useful. That would require multiple steps instead of a single command,
but allow installing the recommends for a specific package at any later time,
which is also useful when they have changed over time or you change your mind
about installing them.

Agreed! And I would also love the possibility to directly paste a
package list from apt show's output into apt install without having to
remove the commas.

Greetings
Marc

[IOhannes m zmölnig]

Post by Marc Haber
Agreed! And I would also love the possibility to directly paste a
package list from apt show's output into apt install without having to
remove the commas.

This!


mfh.her.fsr
IOhannes

[Andrey Rakhmatullin]

Post by Marc Haber
Agreed! And I would also love the possibility to directly paste a
package list from apt show's output into apt install without having to
remove the commas.

This!

apt satisfy

[Marc Haber]

On Fri, 8 Nov 2024 12:53:15 +0500, Andrey Rakhmatullin

Post by Andrey Rakhmatullin

Post by Marc Haber
Agreed! And I would also love the possibility to directly paste a
package list from apt show's output into apt install without having to
remove the commas.

This!

apt satisfy

TIL. Thanks.

Greetings
Marc

[Charles Plessy]

Hello Aaron and everybody,

the R package ecosystem uses control fields inspired by ours. But there
the Suggests field is used in a stronger way: packages listed in
Suggests usually provide functionality that is directly leveraged by
packaged code, and the usual pattern is that if the suggested package is
not installed, there is error catching that leads to a less prefered
alternative or to a message with guidance about installing the suggested
package.

In Debian, if I remember well, I have seen that kind of behaviour with
Inkskape opening a pop-up requesting the installation of extra python
packages when trying to use some filters.

The Suggests field in Debian is not very useful at the moment, but there
is a straightforward way to repurpose it. And apt-get already has
an --install-suggests option.

Have a nice day,

[Julien Plissonneau Duquène]

just to get around problematic recommends in Debian's packages.

What about having a way to configure the packaging tools you use to only
consider a whitelist (with pattern match, pin-style) of package
Recommends? This way you could use your metapackages Recommends while
ignoring others.

One major issue I see with your initial proposal is that if there is
already some room for interpretation with the current fields, adding a
new field is likely to make things even worse in terms of compliance as
there will still be room for interpretation (or misuse) with now two
fields with slightly tighter definitions and some significant overlap.
In short this is a case of "now you have two problems".

[Guillem Jover]

Hi!

Post by Aaron Rainbolt
With all this in mind, I'd like to call some attention to a feature
request made by Patrick Schleizer some time ago, whom I've copied on
this email. The feature request suggests the addition of a new field to
Debian's binary dependency relationship fields, "Weak-Depends".[4] In
Patrick's own words, Weak-Depends "[d]eclares a weak dependency. Most
users of this package may benefit from installing packages listed in
this field, but can have reasonable functionality without them." The
exact way in which this would be implemented is that Weak-Depends
packages would get installed when using `apt install
--no-install-recommends package`, but any package listed there could be
removed without removing the package which referenced the Weak-Depends.
[4]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942303

Given the discussion in this thread, and the feedback on such
potential new field, which matched my own take, I'll be closing the
above bug report, which I had left open in case there was some other
very compelling reason to support it or wide agreement this was
desirable.

Thanks,
Guillem