On Fri, Sep 24, 2021 at 09:26:19AM +0300, Adrian Bunk wrote: > 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.
What I want is for GNU which to stop languishing in NEW, for the dozen people who keep complaining that FreeBSD which is better and some other volunteer should package FreeBSD which to actually spend the 15 minutes to do the work of packaging it, and if anyone wants to retain what I'll call "cjwatson which", to package that separately as well. Any subset of the above allows me to stop shipping which.debianutils post-release, and hopefully not install any which-providing package on my system. > 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] I understand your confusion here: you seem baffled that I think that this is a terrible idea on several levels but am claiming that I will not use my divine-right-monarch-of-Debian powers to prevent the sysvinit-utils maintainers from maintaining their package. I, in contrast, am baffled that you seem to think I have such powers. > 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. I don't have any idea what that means. > 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. Certainly going with my original plan would be even simpler, but that would be effectively telling the people that want GNU which and FreeBSD which that they would need to wait a few years before they can have what they want. > In [2] the debianutils maintainer has now suggested that doing > exactly this for "tempfile" would be tolerable for him. Again, I think that this is a terrible idea, that it would annoy me as a user, and that I have no intention of preventing anyone from doing it even if I could. > 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". To use your word, that would be "tolerable". However, I feel compelled to warn the sysvinit-utils maintainers that they may receive a flood of hatemail and be expected to explain to the `which` enthusiasts why their needs and desires don't matter. If they don't care about that, they can start shipping a `which` alternative immediately. I don't think anyone will send them death threats if they ship `tempfile` too. They do not need my permission for these things. > 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. Policy ยง6.1 hints at why hard-coding paths to binaries is generally a bad idea.
