[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Future of /usr/bin/which in Debian?

Michael Stone <mstone@debian.org> writes:

> On Tue, Sep 21, 2021 at 09:00:52AM +0100, Jonathan Dowland wrote:
>>On Mon, Sep 20, 2021 at 11:02:49AM -0400, Michael Stone wrote:
>>>It seems to install to /usr/bin/which.gnu, implying that you could 
>>>upload /usr/bin/which.bsd if you so desire; what's the issue?
>>I think we should have just one which implementation in the archive. We
>>should (have) pick(ed) the best one for Debian. I believe (perhaps
>>unfairly... I'd love to be proven wrong) that the GNU implementation was
>>uploaded very quickly, without the BSD implementation being considered.
>>Perhaps the GNU one is the best fit for our needs. It would have been
>>nice to see that there was an evaluation.
> I think it doesn't matter how many which implementations are in debian. 
> If you want something with specific portable semantics, just use command 
> -v. The remaining consumers of which are either programs that (ipso 
> facto) don't care about semantic corner cases or are humans who want to 
> use which just because, and probably have strong opinions on how it 
> should behave (as, apparently, you do). We can't satisfy everybody with 
> one implementation, and I see no technical reason that we'd even try to 
> do so.

+1 for everything above.  I also think it may be more reasonable to
prefer (by default, using the alternatives mechanism) the more LSBish
one (in this case GNU) rather than the potentially more simple, clean,
and full-featured one (BSD).  For precedent see netcat-traditional vs
netcat-openbsd, and GNU tar vs bsdtar and pax--particularly during the
time when bsdtar was superior (iirc) to GNU tar.

I also acknowledge that this may entrench the precedent of preferring a
GNU/Linux-standard solution that may not be the technically best.  For
the record, I seem to remember using bsdtar for the period of time when
GNU tar had some issue or another (or was it a missing feature?  Maybe
xattr, sparse file support, or acl-related?), and I also have a strong
personal preference for netcat-openbsd.

Thankfully we have the /etc/alternatives and Provides mechanisms to
affirm user choice in such cases, and I think most of us will agree this
is a totally equitable and reasonable compromise :-)


Attachment: signature.asc
Description: PGP signature

Reply to: