1 |
On Fri, May 13, 2022 at 11:44 AM Mike Gilbert <floppym@g.o> wrote: |
2 |
> |
3 |
> On Fri, May 13, 2022 at 3:11 AM Ulrich Mueller <ulm@g.o> wrote: |
4 |
> > |
5 |
> > Recently Debian has started to transition away from the "which" command. |
6 |
> > [1] |
7 |
> > |
8 |
> > which is a non-POSIX command which prints out the location of specified |
9 |
> > executables that are in your path. Unfortunately, there are several |
10 |
> > versions of the program around which are not compatible with each other. |
11 |
> > We package the GNU version as sys-apps/which, which is in the system set |
12 |
> > since 2004. |
13 |
> > |
14 |
> > Already in 2007, vapier asked developers to avoid which in ebuilds. [2] |
15 |
> > The replacement in most circumstances is "type -p" which is a bash |
16 |
> > builtin command. |
17 |
> > |
18 |
> > So, should we join the "which hunt", with the goal of removing |
19 |
> > sys-apps/which from the system set and from stage1? I think the first |
20 |
> > step would be to identify which packages use which, and add it as an |
21 |
> > explicit dependency. (Maybe the tinderbox could help there?) A bug for |
22 |
> > this [3] has already been filed by mgorny some time ago. |
23 |
> > |
24 |
> > Unfortunately, the command pops up in unexpected places, e.g. it appears |
25 |
> > to be an (indirect) build-time dependency of systemd. [4] |
26 |
> |
27 |
> "which" is a built-in command in bash, but not in dash. For most |
28 |
> users, /bin/sh points at bash and I don't expect to see much breakage |
29 |
> when /usr/bin/which is removed. The bug reports will come from people |
30 |
> who like pain and run their systems with /bin/sh pointed at dash. |
31 |
|
32 |
Oops, turns out I tested with zsh, not bash. Disregard the above. |