Re: Our build system may be broken: /bin vs /usr/bin
Ian Jackson <email@example.com> writes:
> Russ Allbery writes ("Re: Our build system may be broken: /bin vs /usr/bin"):
>> Marco d'Itri <md@Linux.IT> writes:
>>> Actually this is the root problem: policy says that packages should
>>> use the $PATH to search for commands, but your package (like many
>>> others) hardcodes their full path.
>> Policy only says that for maintainer scripts. I agree that it's not a
>> good idea in any location, but I don't believe we've explicitly
>> forbidden it anywhere.
> We don't even have consensus that it is a bug! We have, for example,
> at least one important component which *requires* hardcoded paths in
> their critical configuration files.
Sorry, my "not a good idea" phrase needs more nuance.
I think the general argument against hard-coding paths in maintainer
scripts generally applies here as well. However, there are going to be
exceptions that need to hard-code specific paths for other reasons, so
it's going to have to be a case-by-case determination. A good
counter-example where we do want to hard-code paths is to interpreters
(see previous debian-devel discussion).
I would be pretty dubious of Policy language here stronger than "should."
I would also consider anything other than /bin/sh, /bin/bash, etc. in
shell scripts to be a bug, and I'm worried that some upstream build
systems will generate /usr/bin/sh or /usr/bin/bash if they decide to use
Autoconf to find shells.
Tactically, I'm in favor of not using usrmerge on buildds. I feel like
this is the *last* place we should enable usrmerge, since it's likely to
require all systems consuming the built packages to also have usrmerge
Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>