Any Progress on DEP-18 ("Enable true open collaboration on all Debian packages")?
It's been a while since -devel has heard anything about DEP-18¹, which (Back in August or so) encouraged a large healthy discussion here, and got some coverage on LWN². Is there any news? Where are we at with this (pre-)³proposal? [1] https://salsa.debian.org/dep-team/deps/-/raw/798bfa5a1e1609afd4e48ee20aff80a82bcd4a2f/web/deps/dep18.mdwn [2] https://lwn.net/Articles/986480/ [3] Not actually a DEP at all, yet: at least not present on https://dep-team.pages.debian.net/ -- Please do not CC me for listmail. 👱🏻 Jonathan Dowland ✎j...@debian.org 🔗 https://jmtd.net
RFC: "Recommended bloat", and how to possibly fix it
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 wo
Bug#1086796: ITP: amidiminder -- ALSA MIDI connection minder
Package: wnpp Severity: wishlist Owner: John Horigan X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: amidiminder Version : 0.70.1 Upstream Contact: Mark Lentczner * URL : https://github.com/mzero/amidiminder * License : BSD Programming Lang: C++ Description : ALSA MIDI connection minder Watches for new MIDI ports (both from hardware devices and from applications), and uses a rules configuration file to automatically make connections. Will also handle reconnecting if a port is removed and later added back, like when a device is unplugged and then re-plugged. amidiminder is already included with a Debian-based distro called Patchbox. The Patchbox maintainers have requested that amidiminder be made into a proper Debian package. I believe that there are no Debian packages that provide this functionality. amidiminder is a small package, so I can maintain it myself. I maintain two other Debian packages. I will need a sponsor who is familiar with systemd services.
Re: RFC: "Recommended bloat", and how to possibly fix it
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... A
Re: RFC: "Recommended bloat", and how to possibly fix it
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 Johannes Schauer Marin Rodrigues wrote: > 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). 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 pack
