On Thu, Sep 16, 2021 at 03:02:57PM -0700, Sean Whitton wrote: > Hello Adrian, > > On Wed 15 Sep 2021 at 01:36AM +03, Adrian Bunk wrote: > > > Package: tech-ctte > > Severity: normal > > > > This is a request to override the maintainer of debianutils on several > > changes that were done to the package in unstable after the release of > > bullseye. > > > > > > More specifically, I am asking the Technical Committee to decide that: > > > > 1. The "which" program must be provided by an essential package. > > > > 2. The "which" program must not print any deprecation warnings. > > > > 3. The "which" program must not be provided through alternatives. > > > > 4. The debianutils package must continue to provide the "tempfile" program. > > > > 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. > > Roughly speaking, you're asking for a complete reversion of the change. > > Do you perhaps have a middle-ground proposal which would > > (i) accept the decision of the debianutils maintainer that which should > be removed from the Essential set within a release cycle or so, but > also would > > (ii) include a transition/deprecation plan which would impose less of a > burden, from your point of view, on Debian contributors? > > The TC can't do detailed design work, so without such a proposal on the > table, we're left deciding between a complete reversion and doing > nothing at all. It would be good to have more options.
Talking about "which", it might be good to get an explanation from the maintainer what he wants, and why, and then discuss based on that. Your assumption that the decision of the debianutils maintainer is that "which should be removed from the Essential set" is not clear, there have been statements in both directions away from that. Both the deprecation message and [1] imply complete removal from Debian, not only removing it from the Essential set. In the message [2] to this bug, the maintainer suddenly does not even object to having a "which" in another essential package. Trying to find a middle-ground proposal has already been attempted. When the debianutils maintainer mentioned lack of upstream support and annoyance by requests for additional features a month ago, a maintainer of sysvinit-utils[3] offered to adopt the existing "which" implementation there. This would have solved the stated problems - a maintainer should not have to maintain software he does not want to maintain. This was rejected with "well, hopefully it's going to stop being Essential, because it shouldn't be".[4] The alternative "which" implementations (GNU and BSD) are 30 kB binaries instead of the current 1 kB script, enlarging the size of the Essential set by that much feels like the exact opposite of making it non-essential. Using the alternatives as the debianutils maintainer has now in this bug suggested in [2] just for moving "which" do a different essential package (like copying the implementation from debianutils to sysvinit-utils) sounds unnecessarily complicated, and would require that the debianutils maintainer fixes the race condition in debianutils when upgrading from bullseye. The same can be achieved much simpler with a seamless transfer of "which" to another package as was offered. In [2] the debianutils maintainer has now suggested that doing exactly this for "tempfile" would be tolerable for him. In my opinion, an amicable middle-ground proposal would be that the debianutils maintainer completely removes "which" from debianutils, and assuming the sysvinit-utils maintainers agree, that they adopt both the existing "which" and (at least temporarily) "tempfile". I have not followed all recent discussions around merged /usr, the TC knows better than me whether action is appropriate regarding this point or whether it should be discarded. > Sean Whitton cu Adrian [1] https://sources.debian.org/src/debianutils/5.5-1/debian/NEWS/#L7 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994275#30 [3] a point can be made that this package is misnamed and even the current contents would be better described by renaming it to something like random-stuff-that-is-for-some-reason-essential-and-mostly-unrelated-to-sysvinit but that's a different topic [4] as explained in my initial message, the case for keeping "which" essential is not that it should be essential (that is debatable), but the perpetuity requirement that it should stay essential because it already is (or at properly transitioning it out of the Essential set if someone really thinks it is worth the effort required for doing that properly)