Bug#994275: Reverting breaking changes in debianutils

[Clint Adams]

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?