control: retitle -1 Permit packages to declare dependencies on Essential packages Hello Josh, On Sat 17 Oct 2020 at 04:49PM -07, Josh Triplett wrote: > On Thu, Oct 15, 2020 at 11:56:19AM -0700, Jonathan Nieder wrote: >> >> More specifically, it's the right first three steps. >> >> https://www.debian.org/doc/debian-policy/ch-binary.html#dependencies >> currently says >> >> Packages are not required to declare any dependencies they >> have on other packages which are marked Essential (see below), >> and should not do so unless they depend on a particular >> version of that package.[4] >> >> [4] [...] If packages add unnecessary dependencies on packages >> in this set, the chances that there will be an unresolvable >> dependency loop caused by forcing these Essential packages to >> be configured first before they need to be is greatly >> increased. >> >> I'd propose that as a first step we change that to >> >> Packages are not required to declare any dependencies they >> have on other packages which are marked Essential (see below), >> but are permitted to do so even if they do not depend on a >> particular version of that package.[4] >> >> [4] Functionality is rarely ever removed from the Essential >> set, but packages have been removed from the Essential set >> when the functionality moved to a different package. So when >> depending on these packages for such functionality, it is >> recommended to depend on an appropriate virtual package >> instead. >> >> Future versions of Debian policy may encourage and then >> require including explicit dependencies even for essential >> functionality. This is helpful to users putting together >> ultra-minimal systems (though Debian does not support omitting >> Essential functionality out of the box), and it means less >> work is required in case the moment comes to remove some >> functionality from the Essential set in the future. >> >> (The next two steps would be to change that from "are permitted" to >> "should", and then to "must".) >> >> What do you think? > > That sounds great to me. This would mean that there'd be no policy > violation involved if someone wanted to send out patches working towards > making a package non-Essential. It's a good incremental step. Could I ask you to explain your wanting to reduce the Essential set for the sake of small installation size in more detail, including some numbers, please? It would be good to get to the bottom of Bill's worry about this change, but in addition, I would like to see a stronger positive case. As someone who is not concerned about small installation size, I rather enjoy how the functionality of the Essential set isn't likely to be reduced any time soon. As an example, I understand that RedHat systems aren't guaranteed to have Perl on them anymore; I appreciate how when I'm working with Debian systems, I know I'm not going to have to spend time improving my knowledge of awk, and anyway having to use a tool which I think is worse. I don't mean to suggest that this usecase of mine is decisive, but it illustrates that the benefits of keeping Essential as it is are clear, whereas the benefits of reducing Essential are, currently, vague. Could we actually decrease installation size in a way that actually benefits actually existing usecases if we were to start trying to reduce Essential? I would like to see evidence of that. -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature