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
signature.asc
Description: signature
