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

Bug#850967: marked as done (Clarify /usr/bin/foo should not be hardcoded even in upstream parts)

Your message dated Thu, 12 Jan 2017 15:08:05 +0100
with message-id <5566268.jkBec7eeDs@odyx.org>
and subject line Re: Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts [and 1 more messages]
has caused the Debian Bug report #850967,
regarding Clarify /usr/bin/foo should not be hardcoded even in upstream parts
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
850967: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850967
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: tech-ctte
Control: block 850657 by -1

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.

However, this is not always uncontroversial with some upstreams.  This
causes a particular problem when the upstream is also heavily involved
with the Debian maintenance.


I would like the TC to:

 * Declare that Debian policy should be clarified to say that programs
   in Debian (not just maintainer scripts) should not hardcode the
   location of the binaries in /{usr/,}{bin,sbin} they execute.

 * Say that this applies even when the program needs to find pieces of
   the same (or closely related) package.

 * Say that where technically feasible, this should usually be done
   for other kinds of search paths (LD_LIBRARY_PATH, PYTHONPATH,
   PERLLIB, etc.), too.

 * Provide an informal opinion that this policy ought to apply to
   gpg-agent as requested in #850657.


I don't know if it is necessary to rehearse the arguments about this
issue for the TC, but I will try to do so briefly.


The argument in favour of finding programs (and libraries) on the
PATH:

This allows substitution and wrapping of programs (by adding a
directory to PATH containing a stunt version of the program, or by
adding a wrapper or replacement to /usr/local or ~/bin).  This can be
useful in a wide variety of situations.  It is a well-known debugging
technique.  It can be used by individual users, to modify the
behaviour of their system.  It can be profitably used by things like
test suites and audit tools.  It can be used by depending software to
work around bugs.

Most of these uses can be satisfied in some other way, but the other
ways have downsides.  For example, moving the actual binary aside is a
possibility (and supported by things like dpkg-divert); but it affects
the whole system, so requires administrator privilege; it is
unsuitable on a multiuser machine or for test suites; and if done
ad-hoc it is too easy to forget to put back and leave the system in a
weird state.

Explicit configuration or command line options to change which
subcommands are used are a good thing, but: they are usually fiddly
and certainly not always provided; this can often involve complicated
nesting (eg run `foo' with --bar-program pointing to a stunt `bar'
script which passes --wombat-program pointing to your stunt `wombat'
script); and lack of such an option at any level stymies this
approach.


I will quote the counterarguments from Daniel Kahn Gillmor, as they
are fairly typical of the responses from upstreams:

  In this bug report, you're asking a tightly-coupled suite of tools to
  invoke each other via the PATH, which offers another avenue of potential
  breakage; upstream regularly receives reports from people who *don't
  even know what version of gpg their system is running* because of
  multiple copies of the thing having been installed in various places on
  their system (either deliberately or incidentally, but in either case
  forgotten about by the local sysadmin).

  It's entirely reasonable for a tightly-coupled suite to want to invoke
  its own tools in this situation.  we have enough to debug in GnuPG as it
  is :/

Perhaps this is indeed a problem for some upstreams.  But I have two
responses to this which I think are each sufficient to rebut it:

Firstly, we are talking about this in the context of Debian.  In
Debian we have `reportbug', which the majority of people use to file
bug reports.

It would be simple for reportbug to report on these kind of anomalous
situations and mention them in the bug report.  It could, for example,
check to see if there is overlap between the package being reported
(and its dependencies), and /usr/local.  I don't know if it does
already, but if it doesn't and someone feels the information is
valuable, then I'm sure the patches to reportbug would be welcome.

Secondly, I think the possibility that users may do things upstream
consider undesirable, and even cause lossage, is precisely software
freedom.

The thrust of the upstream argument here is that users must be
prevented from messing with their software in certain ways because it
makes those users' bug reports too hard to deal with.

I think this argument is utterly wrong in principle.  It is contrary
to the whole point of Debian.


Thanks for your attention.

Ian.

PS: Please give the MIPS binutils bug priority.


-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   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.

--- End Message ---
--- Begin Message --- 
Le jeudi, 12 janvier 2017, 13.16:56 h CET Ian Jackson a écrit :
> Maybe I should have tried -devel.  -policy is no good because the
> policy process cannot make controversial changes.

The sequence of your actions on that topic are :

Jan 08: You file #850657 saying "gpg executes /usr/bin/gpg-agent, rather than 
fetching it from the PATH. This is contrary to Debian policy"
Jan 11; after Daniel pointed you to the fact that it _isn't_, there's some 
polite conversation;
Later on Jan 11: you file #850967, asking the TC to change Policy to fit what 
you think it should be, in general and wide terms, potentially affecting a 
_very_ wide part of the archive.

I take quite strong issue with the idea that one can use Policy changes 
(through the TC) to impose one's view on the whole project, and I would have 
reacted much more openly to your request if it had been phrased the other way 
around:
* please override the gpg maintainer to let its tools respect $PATH;
* please consider emitting a more general opinion about this practice;
* please consider setting policy on this;
(Not that I would have agreed on any of the three.)

You phrased it like:
>  I would like the TC to declare that Debian policy should be clarified to say
>  that programs in Debian (…) should not hardcode the location of the
>  binaries in /{usr/,}{bin,sbin} they execute.

That's quite different.

The point is: I expect people bringing cases to the TC to start with try to 
solve the _actual_ technical problem they have, and then (only _eventually_) 
expand to the wider "problem".

I would be quite surprised (and disappointed) by a TC agreeing to set policy 
making a large number of packages de-facto buggy, even if there are certainly 
cases where it could make sense [0].

> I suggest that the TC close #850967 NFA, and that the Debian gnupg
> maintainers tag #850657 wontfix (and perhaps close it).

Ack. Hereby closing this bug then.

> I won't promise to stop asking Debian maintainers of other packages to
> make this change, when it trips me up.

Noone asks you (or anyone) that. I think it was eloquently phrased in this bug 
thread: there are cases for both approaches, and maintainers can be rightfully 
convinced both ways. Filing bugs asking to remove hardcoded full paths in 
favour of executing from PATH is entirely fine; it doesn't imply that 
maintainers (or the Debian Policy) have to agree with you for all cases.

Cheers,
    OdyX

[0] One could argue that this is what happened in the 'menu' case, but there 
were a lot of efforts spent to resolve that case via consensus, and these had 
been tried and failed.

Attachment: signature.asc
Description: This is a digitally signed message part.


--- End Message ---
Reply to: