On Tue, Oct 26, 2021 at 12:46:43PM +0200, tito wrote: > It is possible to create a single command package if somebody > will maintain it ( e.g busybox-which) like it was done for busybox-syslogd. > tempfile is missing tough.
If someone wants to do that, I suppose they can. On Tue, Oct 26, 2021 at 01:53:29PM +0100, Wookey wrote: > I didn't understand why you wanted to make this change in the first I think I tried to explain this to you on another mailing list. There are people who are dissatisfied with the status quo with respect to which(1). I, as a user, don't care at all about which(1). I, as debianutils upstream, do not want to spend any effort maintaining a utility which is superfluous given the existence of alternatives which are preferred by people who care about this stuff. Now, as a debianutils maintainer in Debian, I could choose between various different approaches, taking into account different objectives to accommodate different stakeholder groups. It is important to acknowledge that it is impossible to please all groups here. One approach is to embrace the status quo. which(1) is perfectly fine as it is, and anyone who wants `which -s` or `which --read-functions` is a fool, an idiot, or worse. Those people don't matter and they should shut up. I believe that this is roughly equivalent to the original demand at the start of this bug report. I'll call this the ultraconservative approach. It is predicated on bad values and produces a bad outcome. Another is to cautiously embrace change at a glacial pace. This signals to people who want something else that they are largely unimportant, but as a gesture of good will, they can be accommodated eventually, maybe in 2 years, maybe in 10. It might seem reasonable in a subculture which is stratified and resistant to change, with stability (even the stability of _unstable_) paramount. I'll call this the conservative approach. It is predicated on bad values and produces a bad outcome. Another is to build a runway for people to get what they want and remove myself from the equation. This is what I have attempted to do. Now, provided anyone elects to maintain them and the FTP team allows them in, users will be able to install and use GNU which, *BSD which, busybox which, rewrite-it-in-rust which, or whatever should float someone's boat. I can think all of this is pointless, and it doesn't matter, because I am not impeding anyone else in their pursuit of which(1) apotheosis. > place, and I don't understand why you didn't just revert the message > when it became clear that it was a problem, and I don't understand why > you are still trying to justify your somewhat bloody-minded approach > to this (should-have-been) minor issue, even after the tech comittee > have agreed that it was not a good approach. You seem angry that I haven't expended effort to work around a bug in some other software. You also seem angry that I am not following a process that I am explicitly calling a bad process. Other people have said that "this is the way Debian does things," but I have been doing this for 25 years and I recall Debian doing things many different ways. I'll save my commentary on the quality of the TC's decision until after they have made it. > Please, just remove the deprecation message, until GNU which is in > unstable (like you should have done a couple of months ago, when first > asked), then work out how the transition should go such that no-one > using which will actually notice or care. Then you can throw away the > hated binary :-) and we can all be happy. When will GNU which be in unstable?
