On Wed, Sep 15, 2021 at 09:20:34AM +0200, Helmut Grohne wrote: > On Wed, Sep 15, 2021 at 01:36:26AM +0300, Adrian Bunk wrote: >... > > 1. The "which" program must be provided by an essential package. > > This request seems overzealous to me. Banning the shrinking of essential > would set a bad sign in my opinion.
This is a misrepresentation of my request. I was making the case that making this specific widely used program non-essential would bring "close to zero benefits" due to its size. I was even writing: > > As Helmut Grohne has demonstrated in recent years it is possible to > > remove functionality from the Essential without causing breakage when > > done carefully. Everything regarding this point was worded with the intention to limit the scope only to "which", not a general banning of shrinking of essential. >... > > 2. The "which" program must not print any deprecation warnings. > > The request for this decision again is rooted in the amount of work that > was caused to others. I am unsure whether the request being made here is > too specific and leaves too little room for actually performing the > transition in a sane way. Are you arguing for a transition that makes "which" non-essential, or are you arguing for a transition that would remove "which" from Debian? "deprecation" implies intended removal at some point in the future. > > 3. The "which" program must not be provided through alternatives. > > I disagree with this. There is prior art for using alternatives in > essential packages, e.g. /usr/bin/awk. This hasn't been a problem > earlier. > > > It is also incorrect that the essential "which" in debianutils would > > have to use alternatives if someone would want to package a more > > featureful different "which" implementation. A different "which" > > implementation doing dpkg-divert of the essential "which" script > > would be a more logical option. > > While it is difficult to disagree with this reasoning, I'm unsure > whether it is sufficient reason to override a maintainer. The current implementation is something where the maintainer has to be overridden to prevent breakage. Currently there would be a clear violation of policy during bullseye to bookworm upgrades due to the program "which" that is part of the essential set not being available between unpack and postinst. If really required there might be hacks that could fix this problem. But what is the long-term goal? awk needs alternatives since there are permanently more than two implementations in the archive, that might all be installed at the same time.[1] With the deprecation warning the debianutils maintainer gives the impression that the intended number of "which" implementations in Debian would be zero. > > 4. The debianutils package must continue to provide the "tempfile" program. > > The request asks for tempfile being kept eternally, but the reasoning > does not: > > > Different from "which" an eventual removal of "tempfile" might be > > desirable, but this would have to be done in a coordinated manner > > by first getting all reverse dependencies fixed in a stable release > > instead of the current situation where the program was removed > > breaking reverse dependencies. > > Again, the criticism is with the process, not with the outcome. I agree with you that removal might in general be desirable in this case, and that my request about criticism with the process should not be eternally. I am changing this to: The debianutils package must continue to provide the "tempfile" program, unless removal follows a transition plan approved by the chair of the Debian Technical Committee. > > 5. Programs in debianutils must not be moved to /usr unless there is > > project-wide consensus on packages doing such a move, and premature > > moving must be reverted. > > We still have a quite similar change in debhelper that moves around > systemd.service files and do not see a need to overrule the maintainer > there even though that also caused breakage. I do not think that raising > this issue with debianutils only at this time is appropriate. Indeed, it > seems to be a direct result and reasonable interpretation of an earlier > ctte decision, that now results in a similarly poor transition. If > anything, that decision needs to be updated. I wouldn't have gone to the TC only for this point, and this point is only temporary. > As a consequence, I ask the ctte to quickly rule on the process aspect > of the issue and slightly defer the more difficult questions. The longer > we wait, the more harm is caused. > > A possible outcome could be: > > 1. debianutils needs to temporarily revert changes that cause breakage > elsewhere including the deprecation of which and removal of > tempfile. Points 2-5 in my request should be listed explicitly, with that change it would be a good short-term injunction. > 2. Before including the changes in debianutils again, a transition plan > must be presented to debian-de...@lists.debian.org. It must ensure > that the majority of resulting issues are fixed in unstable before > including the changes in the debianutils package. This does not work with a maintainer who is not being constructive. "majority of resulting issues" sounds like an invitation to not fix everything, and "presented to debian-de...@lists.debian.org" does not include a requirement that anyone has to approve it. The widespread breakage by the debianutils changes is known to the maintainer but has not resulted in reverting the breaking changes. After the debianutils maintainer said missing upstream support was a problem for the current "which" script, the maintainer of another essential package offered to adopt the tiny "which" script from debianutils into his package. This was rejected. > Helmut cu Adrian [1] and because it's a virtual essential package
