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

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

Nikolaus Rath wrote:

>>> Policy 6.1 says
>>> | Programs called from maintainer scripts should not normally have a
>>> | path prepended to them.
>>> Ie, programs that are on PATH should be found via the PATH rather than
>>> by hardcoding /usr/bin/foo or whatever.  In general, I think we
>>> normally, at least in software written specifically for Debian, apply
>>> this not just to maintainer scripts but to all program execution.
>> I agree that it's a common practice for software written specifically
>> for Debian.  I'm not convinced it's a common practice elsewhere, and i'm
>> definitely not convinced that we should mandate divergence from upstream
>> for this purpose.
> Just as a datapoint, in other communities there is actually a trend in
> the opposite direction. For example, for the Python ecosystem there is
> an increasing drive to establish a "system Python" that ignores Python
> modules in /usr/local and $PYTHONPATH, specifically to avoid potential
> interference of user installed modules with distribution Python scripts.
> I have a lot of sympathie for this idea, and I think it would be good to
> keep this in mind when discussing potential clarifications of policy.

Nikolaus highlights two failure modes that we see sufficiently often that 
#debian even has boilerplate help text to deal with them:

* user installs their own version of python in /usr/local and then packaged 
python programs start failing (missing modules, incompatible interpreter 
etc), possibly even to the point of breaking package installs/updates such 
that the user can no longer use apt until they work out that is the problem 
and rectify it.

* user installs their own versions of python modules in /usr/local and then 
packaged python programs/modules start failing because the new versions are 
incompatible; this can also easily break maintainer scripts and so break 
package installs/upgrades.

By giving the local admin the ability to override tools using their PATH we 
give them great power and flexibility at the expense of robustness. We give 
the user a loaded gun, help them aim it at their foot and then stand back. 
Shouldn't we be trying to engineer robust solutions rather than footguns? Is 
helping people to accidentally break apt a good thing? Is opening the door 
to subvert gnupg¹ where we want to go? The principle should be one of 
isolation not accidental, unwanted and detrimental coupling.


¹ wild (but fitting) hyperbole; then again, let me quietly add something as 
group:staff to /usr/local/bin...

Stuart Prescott    http://www.nanonanonano.net/   stuart@nanonanonano.net
Debian Developer   http://www.debian.org/         stuart@debian.org
GPG fingerprint    90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Reply to: