FS#56997 - [xorg-server-xvfb] missing dependency on `which`

Attached to Project: Arch Linux
Opened by Daniele Cocca (jmc) - Monday, 08 January 2018, 00:41 GMT
Last edited by Andreas Radke (AndyRTR) - Wednesday, 21 March 2018, 12:53 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Andreas Radke (AndyRTR)
Laurent Carlier (lordheavy)
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

The xvfb-run script [1] requires `which`, but this is not listed among the dependencies [2].
This can be fixed by either adding an explicit dependency on `which`, or using the POSIX sh builtin `command -v ...` [3] to perform the same operation without introducing additional dependencies.

[1] https://git.archlinux.org/svntogit/packages.git/tree/trunk/xvfb-run?h=packages/xorg-server&id=94da807f6fb18360c36249eea7cbbf52cef624ee#n139
[2] https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/xorg-server&id=94da807f6fb18360c36249eea7cbbf52cef624ee#n176
[3] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html

Additional info:
* package version(s): 1.19.6-2

# Before installing `which`

$ xvfb-run some_command
/usr/bin/xvfb-run: line 139: which: command not found
xvfb-run: error: xauth command not found

# After installing `which`

$ xvfb-run some_command
# (success)

Steps to reproduce:
* install a base image (e.g. pacstrap)
* install xorg-server-xvfb
* run `xvfb-run some_command`
* fail
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Wednesday, 21 March 2018, 12:53 GMT
Reason for closing:  Fixed
Additional comments about closing:  fix commited to trunk though ideally not needed...
Comment by Eli Schwartz (eschwartz) - Monday, 08 January 2018, 00:58 GMT
Hmm, `which` is part of the base group, and we don't have any policy about implicit dependencies on the base group... so technically any system which does not have it installed is in the wrong. That being said, using shell builtins is obviously superior on at least two levels.

xvfb-run seems to be imported from Debian, have you considered filing an upstream bug report against Debian to fix this?
Comment by Daniele Cocca (jmc) - Monday, 08 January 2018, 01:44 GMT
Debian seems to be OK in that the `which` command is provided by `debianutils` [1], a dependency of `dash` [2], which by default provides the /bin/sh interpreter.
I'm not familiar enough with the Debian packaging policy to know if a direct dependency would be in order here, but the above means that in a default setup all works as expected.

[1] https://packages.debian.org/stretch/debianutils
[2] https://packages.debian.org/stretch/dash
Comment by Daniele Cocca (jmc) - Monday, 08 January 2018, 09:45 GMT
Actually just checked, Debian policy states packages should not explicitly depend on "Essential" packages, so this is WAI in their case: https://www.debian.org/doc/debian-policy/#dependencies
Comment by Eli Schwartz (eschwartz) - Sunday, 21 January 2018, 02:49 GMT
So if this is a legitimate bug for Debian as well, where is my upstream bug report? ;)
Comment by Daniele Cocca (jmc) - Sunday, 21 January 2018, 16:50 GMT
As stated in my last comment [1] I don't think this is a bug in Debian, so I don't think it warrants a bug report upstream.

[1] https://bugs.archlinux.org/task/56997#comment165231
Comment by Eli Schwartz (eschwartz) - Monday, 26 February 2018, 16:42 GMT
We could also just update to https://salsa.debian.org/eschwartz-guest/xorg-server/blob/debian-unstable/debian/local/xvfb-run

:)
Comment by Andreas Radke (AndyRTR) - Wednesday, 21 March 2018, 12:50 GMT
In Arch we expect full base to be installed. So not a bug in a clean Arch system. For safety I've added "which" to its deps anyway for people like you.

Loading...