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

Re: Our build system may be broken: /bin vs /usr/bin

Ian Jackson <ijackson@chiark.greenend.org.uk> 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 (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Reply to: