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.

Some of the advantages of this solution include:

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
--==============09281523076296886=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

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

iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmcqxj0ACgkQ8sulx4+9 g+Ezeg//YxCU/nGjvdxP8/xxRUijx8yoFtkYCLM9pZEl3wzvYhUXum9A//gJrchX WLBbl9/JkZNqNuEA6qppF66qeFgNXc0HR6c56K0d1DHPf5JtgIeCkf7ouoJ1WuOV S+d1K1GLhnAhsq2mfwf/oN1qz/lfNnOvsXdupvF6vjHQqZnZPoikrVSMQ8redg17 TzQ90D9maOwESjf3OfSB0vjTm7hiRHPdNp/CSVJLCg6Pd0ItQ4jDFRt/QmvbXBLT CooOgkfywFO3dTQCppxehLvWY/qJqPTrFCUrq7pbF1/hwg/X28Ko5x+mX+jYN8VB +HNa63NhEkoSuoX7N7rb6fy5VdCztSRquFph/wigY3YvkC9gn0oIPOmYE84rk3Ud BuhBmMICHvKwH7SNLAzwLbehaW7gXIPw4k65kcrJbuy+HsYIw7wc0+u3yXfHpKH6 FGXui+jHsNMygmIRTvixTRYClz/xe+K5FZX4pO1vJQqK4g/hHOnq0/5iZgxhqSw4 6HZQef9t12G++CzRN4f90psIF4NgUMHMBeDC8LbonjjwNs52MnmvTNEJMsqnDK8z MQtf2DcTAa6mFCeOGEA2pJMkq86bqxJEL4hP+g5AhJ3zttF1DgNZ9i1DdcIPHgFZ T24cftvF0zBPhOB5XH8pjrpabcIzNnypEeIVmaDVB2wMSFGMK4A=
=JITc
-----END PGP SIGNATURE-----

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

* Johannes Schauer Marin Rodrigues <josch@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

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

Am 6. November 2024 00:35:59 MEZ schrieb Aaron Rainbolt <arraybolt3@gmail.com>:

* 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

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

[Added diffoscope@lists.reproducible-builds.org to Cc]

* Fay Stegerman <flx@obfusk.net> [2024-11-06 17:43]:

* Johannes Schauer Marin Rodrigues <josch@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.

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

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

On Wed, Nov 06, 2024 at 06:03:45PM +0100, IOhannes m zmölnig wrote:

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

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

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmcrr1sACgkQCRq4Vgaa qhzxyA//XOWGOqNncNK343S6HaQRzA2q0OPJSOLvec6iXFcF86ykr6ODyIoR/u9K bxkrU47up/uLu067+BKSdIHDtB7h69ZchuQhw3qzWvsKtntSXhIzggMHP6oKAKmN 6SOcnFpSoU2y6zmJ0uwEC6KG+cAHVOI2OpsPGM5qGR9fQlvUD00eAzV3ncBLD2lb Da+eT1Fc56y4fX4BbwXRZ0UAvwbzFdF2ULJKYCI3dAzHp7VswDY2JiLbr8ZCv1Kh hkoP+hCs7vIT+hZRx9B1+wTp2qU9Cx/unK1DjPZ/+oSDk3DLGoIqgF6nSp3T3vDi Hmn2ywFUyxEQKSiSY9HwDUhJ3fGwWPwxwUK1ZK8e7bLnd9iORaVFTjTW1h8/sFTe AsILw0vNh80TivT0qRWr7ENGfltbtvjmO3rS7q2fM/ciHWi6PnmnHOS/BTeAwa8v 3EETDVj2o4QTm6VOgez3tQ+Zpct1uatQWUNFloSc2m2lO6JgAXUmYqDuJazjslBt NgG5dLV7mv9fCH11lwx6cUZA2O6+ewN8QwLT9lHS77wNlJqa66nE9rf3mX86

Fay Stegerman <flx@obfusk.net> writes:

[Added diffoscope@lists.reproducible-builds.org to Cc]

* Fay Stegerman <flx@obfusk.net> [2024-11-06 17:43]:

* Johannes Schauer Marin Rodrigues <josch@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.

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.

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

On Wednesday, November 6, 2024 12:08:07 PM MST Aaron Rainbolt wrote:

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.

--
Soren Stoutner
soren@debian.org
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEJKVN2yNUZnlcqOI+wufLJ66wtgMFAmcr3doACgkQwufLJ66w tgN4Tw/6AoQouRPoMbD1dqlbU29Mvm+OCPhsAT1EweKdoir4EFXXKpFn1Y/dRzua 5pqyiMvPDfWbD3txyJiBtA1FgdiZY06Yrna4mUjEDglkFNp5Scyou8s8Gwsg4+6d LZAk7VTOmcjODwjE3pxFDUvM/tWWNgdHh6p0bcRp8mngNZqLrLocx/yvC8Acosg5 TyUdy6ptdNDwvZZRO2xug+2CCoUX8mRNGbTWYfx9zuJhk0uBlrnTbGFPLFnVC7j2 x3eJKtkaQ2ijkeKrEVv7AzzjIZ7zhSKlgKYsZmh51EGzlQPA6Vs9W0yizkN0wpac n2uaqwp/4kZYS5kyG/b9NEt5+1BN98Psdoq4uKGADByS+DjUphJN2xWiw9WUW6P8 LQQmW3Wm47/IqD9Ssr1fo7Jf/lulPL7gN4SWGw0jd3SXOiZLs7vUz1AninoREWRq yMYB5d0QgO/8grd7cb3YDCYfEULCu0vCKLJtD7s8Z598YcqzbgV8+8uPf16EFCGh rkgFNTzkP3oIbRFotNXgSSgXSOZfIPYMrhigglhNKvGOEDQI6KWozhM+0NV0vfOM IhQM1MlprHBP2NpM//F35uJXotB3YaXiCoNcjiBBLxuFLVQCWkHAivBi8cGJ0abZ /eFVpTmo9pb7egZVMBXOWIh21axRaA1Ki8KjbxNqohv0+ThwtxI=
=792m
-----END PGP SIGNATURE-----

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

On Wed, Nov 06, 2024 at 04:06:59PM -0600, Aaron Rainbolt wrote:

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

--
Colin Watson (he/him) [cjwatson@debian.org]

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

On Wednesday, November 6, 2024 3:06:59 PM MST Aaron Rainbolt wrote:

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

--
Soren Stoutner
soren@debian.org
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEJKVN2yNUZnlcqOI+wufLJ66wtgMFAmcr9MoACgkQwufLJ66w tgP74w/+Latv8oju0OTNi5K0h26DKTseWvGIx2DNK2rKDOQYKfHOAndAQrC1qelt kHCRUbq70+xQ5xlCOFSwWcOxDtN8/4+DxPiavr01IyTll9qnryywnC7gszOs/SPH eXTf8mznazP4noOB0k5Xi7Q/sL0ZZhR+G4LfoKPsBEonHw3RYxnwY+sRBBHrVdpi QT3fQYjeeO66x2cqzkj/MUPA+kVNQOnfUMP60mPlFms/v1NKkB6thR1+VA9XAOh/ /O/ir1j1iiLOiDyxRwuaDzIPLhYlGWxmp69T+BCPV9a8a3E/D9q+pYSdWg+XVPzm ZMnJszGXLDh7T1wZi6of2PvHp8A8kuMDbucjBqK6N6FjuKq07V9aZ3pO4sIpaE8w FGmMrtkOMbbYFCwtTvOA6W2YiXpInu/dQNUla4qMTbWti77lRtBaHlr3ZeJi+U3B Pj3d4i+g0jlWb0LMS7wMGZ9UomwArdEVMG+Xh6XAi2lWVQdE8s+8g+GP8Jlwuroj N6xZhpJ5+jIAMSarwl6AlbHtObtYUL3011CRagZbGte1zB3RmjHRR241qatRk2V/ 48HXF4/iLOm2MtltaoKR1HjPlWASN225nV5NY3Khe7DC3G7rHliFPyOw1QC8sQAb kCeqTKWX45+Snlmc6r9n9Ihnj+Ya6fVK5SEoyik+mcsjgcmYfxk=
=+j9s
-----END PGP SIGNATURE-----

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

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,

--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from home https://framapiaf.org/@charles_plessy
- You do not have my permission to use this email to train an AI -

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

On Wednesday, November 6, 2024 8:12:29 PM MST Aaron Rainbolt wrote:

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.

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.

--
Soren Stoutner
soren@debian.org
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEJKVN2yNUZnlcqOI+wufLJ66wtgMFAmcsRQcACgkQwufLJ66w tgMhYA/+Krm+Wwd0AN11mNQboWLm7IcmMm94i6pjAXhxQ6shbarzRnmZGqmyBWM/ Bb+yoUYocJu/HochWjZvVSMHb5awDNsuE2fufVx6U0dDbPpe9YfXiw+ksWQhCllY 5NvzieqV+XU/UJbFjNZhDYTXEhrAvMavIU10xC82rzsFr/4Y3844Ifh6j13AAcKB YwlWhyeO/7M1OWG6jUIwKbMFPHynE7HtCw57Oy7KWQqyJMqNMzTPdy3pQ/Ew1tOa szPG9w1BJf+4yonSJYLhSXRgu7MZJghX0a014pjr2JmG3mtDDMSrrKUICUbr5LCZ GReYC1iIuqYzthzXvnPQLEu/nydRFon5JDhsgd3EZZ8ilytGCwrbvBst4JNNNyAq x+H84rsAnX1rCFBf7do4f3qRWFZgLu5Omk96zdxLS9ABHHxE7t8hoxEbj8gCFmLX ZJynpuWbBBlRUF4jUY/ucVPUfjuCtAXKCWpSKrrrngxJzuD5XjluFx/3PJjjSIyl FeA/UwH7NTpaDom7UjJLusPFqSo+NxKiCHTK7D4q9IX5n7Vgq0MGRt/UPtn2+pFX tsp+bk1Rz12dvh+2FboHdNLQnrGvIWaD4a99PnRRK2LPSnYWuFACNxMWArFnBC+Q DdTdspSTnOxmwQpkCreF/Acp402Ody3hrzf335g82RgKv4EVqb0=
=7UiV
-----END PGP SIGNATURE-----

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

This is a multi-part message in MIME format.

--nextPart18419584.9OCd13akkR
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Wednesday, November 6, 2024 10:41:46 PM MST Aaron Rainbolt wrote:

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. --nextPart18419584.9OCd13akkR
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="UTF-8"

<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body><p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">On Wednesday, November 6, 2024 10:41:46 PM MST Aaron Rainbolt wrote:</p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; Again, this isn't a problem limited to a derivative distribution. I</p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; respect that your opinion of how Recommends should work differs from</p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; mine. That doesn't change the policy though, and it doesn't change that</p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; neglecting or changing the policy's rules in this area will cause and</p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; is causing problems to some of Debian's users. Ultimately I don't care</p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; exactly how those problems are solved, I just want to solve them.</p>
<br /><p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">Let me try to explain what I see as the core of the problem.</p>
<br /><p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">First, some background on the three existing categories.</p>
<br /><p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">1.&nbsp; Depends:&nbsp; These are the packages necessary to install and run the basic functionality of the package.</p>
<br /><p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">2.&nbsp; Recommends:&nbsp; These are the packages required to enable all the features of the package.</p>
<br /><p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">3.&nbsp; Suggests:&nbsp; These are packages that enhance the functionality of the package.</p>
<br /><p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">Enabling a feature in the package is a &quot;<span style="color:#232629;"><span style="font-family:Noto Sans;"><span style="background-color:#f8fbf9;">strong dependency”, which
is what is meant by the policy.&nbsp; 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).</span></span></span></p>
<br /><p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;"><span style="color:#232629;"><span style="background-color:#f8fbf9;">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.&nbsp; 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.</span></span></p>
<br /><p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;"><span style="color:#232629;"><span style="background-color:#f8fbf9;">Some packages are clearly in Depends, Recommends, or Suggests.&nbsp; Others might be right on the line
between two of the categories.&nbsp; In these cases, a maintainer has to make a judgement call.&nbsp; 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.</span></
span></p>
<br /><p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;"><span style="color:#232629;"><span style="background-color:#f8fbf9;">Some upstream projects are complex enough that the above three categories don’t fully capture the needs of
users.&nbsp; In those cases, meta-packages can accommodate those needs, as has already been discussed (which is analogous to Python &quot;extras&quot;).&nbsp; 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.</span></span></p>
<br /><p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;"><span style="color:#232629;"><span style="background-color:#f8fbf9;">With all of that said as background, the reason why I am opposed to what you are requesting is that it boils
down to:&nbsp; &quot;Please create a package category that only installs the important features instead of all the ones I don’t use”.&nbsp; 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).</span></span></p>
<br /><p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;"><span style="color:#232629;"><span style="background-color:#f8fbf9;">What I don’t like about this idea is it requires the package maintainer to be a mind reader.&nbsp;
Specifically, they need to read *your* mind, because every single user has a different list of what the “important” functionality is.&nbsp; What you or your distribution considers important the next user or distribution would say, “I never use that,
take it out.&nbsp; But I need this other thing.”</span></span></p>
<br /><p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;"><span style="color:#232629;"><span style="background-color:#f8fbf9;">Maintainers would end up having to create multiple variations of each package to make everyone happy.&nbsp;
It is unsustainable.&nbsp; 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.&nbsp; Don’t ask
the package maintainer to read you mind and guess at what that will be.</span></span></p>
<br /><p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">-- </p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">Soren Stoutner</p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">soren@debian.org</p>
</body>
</html>
--nextPart18419584.9OCd13akkR--

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

iQIzBAABCgAdFiEEJKVN2yNUZnlcqOI+wufLJ66wtgMFAmcsZ2YACgkQwufLJ66w tgMiuRAAldsC7zwJYfxdPBnQE7PGnMVr6dHWleQedN56nEWhr7V7BZfc+DaUqC4A S4zoJTtqIg7veBrLP5GmEnB49m5kNSnr2oOk+P1+/btN48aGS9ILmbjQyQVRnNa/ dTnbm9xIedDO3P7zOyyZD61pbTrioc00aF8xbE0j5NuGURFcRLS1QAoOZnoGzovr yxPlbWhBAJsV9neBVIOWV2hgeZCXiUvmjJ1onc4FTNYMlL1mMqpxZ53g2kyBaJCG JtehuomzrVEqOcc8jWB/VNkGc/jtUx3mjiK3Zm3dlzUNa3U6WNyGOb79eoy3D1wA wRofN4/cFJ7Ljo5b0GC7lVXUmJbwohWs8baY464m2twkdEi0Kj9qUe0dB8M7c08I wEtQPZKH4L61z/G1hh/cdFPKgHWp72sME4qKgMQT8c1QTP1Af099K+JqCXzA2V8J nYkFU5gy3xIwAjn9OiMsG5a+vGym5CuG8zFXlVNeF9t91+E48Gqe1cImtCNTuLne yDzTFISRRCtzOA3wR0Ple9itfRqtw5GpiEndV3Hd9MX/B7fYwKgc++U/sDU0maJd o6gN7uXN5dmBRC3jBI5vAHF5ASldd/JnxslgZ1zcKf2QTsSwX7BlqoxtRWdJ5ziR Glk9ZO7OP2OaF+j2g0fPJxm1yNpbI61MmM+d8cyqSUdXJVd02oc=
=NNK3
-----END PGP SIGNATURE-----

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

On 2024-11-06, Colin Watson <cjwatson@debian.org> wrote:

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

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

On 07/11/2024 04:12, Aaron Rainbolt wrote:

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

--
Julien Plissonneau Duquène

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

On Wed, 06 Nov 2024 13:08:07 -0600, Aaron Rainbolt wrote:

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

--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`-

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

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmctTPJfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ qgay/g/9HDclkZtHdrxHLJRRJPEiVBaCpE+YJnufXZ6kyZLdVvoXwfLiHAsVtH+Z K9WhAgy8q+HaKWNPVGqRQ8YCUxx2FAPpn/DxYDu+R/lIoav4Lore5u3AzeQMZVXu YoSUjZEJLigef9bSKdFIneoI3ELf1QD9AcRoA7PXi3E1RXPSaq1ziUTlvnNOdUwY AowYXym7r7tAp7wPFZdXsujP6Wy/wSO/SbVvdKmWvjrQXVhWD1351YTJ9H1oVIyM Hwn6LxL433XMIfftSQYVuRh4bGpZTzHHQblpclZyAx06ZRzuCSEyHC5NJ6E5F6UI DvijkMmWUI4GNqaV3iDezBknHFYAXFgdDUWlifA/eCFsgBIUHzsyVQb7fHDNDv19 6QE9V9zcdH78VNZh93YHnDIIElvYlVjCDwjO/aJKrmgYt0UPrc80b1XL6T+NwcoM On+OORGZb3ySXatQkn129DlzG4VaUVQFMOLSoavCcXMZMykWgp5boOjAPXhwGsPk
0e1pJN0H

On Thu, 07 Nov 2024 00:08:22 -0700, Soren Stoutner wrote:

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

--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`-

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

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmctSnlfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ qgY8cxAAwFQQzd8nP1JHAIHjxV7tSoTqH6GwCUV7FvC84K/+hMBs6vZNsWFHehmq SysVFdOmJ0PQ8XoCmA0tnjpIYmUs19RXyyV9kRFUxtTjK4Ja1FCFNZvF4DYsvSyH /Xdf635tb8rengWb1/1faeWd44xUK3a4XjdtGQKwLAHmPmsxSFCuXwrZ+8TdStUO sAdDqbyen04exCjaJaeF+3x/K2S3b+p+C9dJNll4om4zWcELBMCFg+6s2o+ho0Z4 yLzZ/Rh4hxkpr3gSk83tivzJKm1RMNQX3UtLIeynERp347EQGxrlmRGdfD2e9yHx jn9l5eNruNTyE3rJL/symR33RmJmGgBSkAEjp3BIvy80tRDN9uPKRpKOHmKX7SDZ x1IRcuOYODs6tyXblwSm8YCOSr46agszuVYULEYTihF91yAcA/qw/maD1N0PiiMq D2gCnYpanq9YEn3UPLQTucK1Gja8xcpJkCkyck129VzoXRqug0UjtwaSkRmU8zCE BzjFG+wEndfbMq9GnTjIBKzO23ZaQ9aMQ7gA88QwGIOdLWQLY+/bv5o/BMc4dIi5 jI3MJnGgLS26vHf15xd+LRwjrVEtAunHVs4pTCCoprlJ7FbXdXjaamMTyoQ36ef+ qr4kCxmhj9Wnv77IYxtEJFShfuX+xpnCqT+2MnGQ3ajcI/WGYUM=
=7I3s
-----END PGP SIGNATURE-----

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

On 2024-11-08 00:17, gregor herrmann wrote:

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

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

On Thu, Nov 07, 2024 at 12:08:22AM -0700, Soren Stoutner wrote:

On Wednesday, November 6, 2024 10:41:46 PM MST Aaron Rainbolt wrote:

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

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

Hi!

On Tue, 2024-11-05 at 17:35:59 -0600, Aaron Rainbolt wrote:

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

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