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.
cheers
Stuart
¹ 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: