Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts [and 1 more messages]
Josh Triplett writes ("Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts"):
> I find it surprising that this has ended up in front of the Technical
> Committee before it has, for instance, ended up on debian-policy or
> debian-devel for discussion. While Policy would not make a change that
> would instantly declare a large number of packages de-jure buggy, those
> two lists nonetheless seem like the right place to have this discussion
> outside the context of any particular package.
Maybe I should have tried -devel. -policy is no good because the
policy process cannot make controversial changes. (As an aside, the
process also so little rewards the policy editors with autonomy that
it's not an attractive task, so the policy maintenance is slow due to
lack of effort.)
Stuart Prescott writes ("Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts"):
> Nikolaus highlights two failure modes that we see sufficiently often that
> #debian even has boilerplate help text to deal with them:
> [python things]
Thanks for the data points. This is troubling. I know that Python
has historically had confusing approaches to its include path
> 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.
Perhaps this is indeed true for Python.
Anyway, I don't think this request of mine is going anywhere. I'm
definitely still unconvinced about gpg-agent (#850657) and I'm
disapointed, but there is no point wasting any more of anyone's time
I suggest that the TC close #850967 NFA, and that the Debian gnupg
maintainers tag #850657 wontfix (and perhaps close it).
I won't promise to stop asking Debian maintainers of other packages to
make this change, when it trips me up.
Ian Jackson <email@example.com> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.