Hi Ian (and hi tech-ctte!)--
On Wed 2017-01-11 12:13:44 -0500, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
> Package: tech-ctte
> Control: block 850657 by -1
Ian, in the future please x-debbugs-cc me when you take our discussions
to the tech-ctte :)
> 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. Please see the examples i've already given in
#850657, or run
find {/usr,}/{s,}bin -type f -print0 | xargs -0 strings | egrep '^(/usr)?/s?bin/[[:alnum:]]+$' | sort | uniq -c | sort -rn
on your own system to see that it's not actually particularly uncommon.
> * 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.
Please do not do this to gpg-agent unless upstream is fine with this
change. I have more important things i want to consider divergence from
upstream about, and i don't think this particular scenario is a healthy
use of debian policy.
I laud Ian's goals of making debugging easier, but the particular
pattern he describes (wrapping stuff and putting the wrappers in $PATH)
is not the only way to ease debugging, and is at least as vulnerable to
the problems he associates with other techniques ("too easy to forget to
put back", etc) as they are.
> 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.
the majority of debian users don't file bug reports at all, sadly. they
complain about brokenness to their friends, they grouse about it on
social media, ask for help on stackoverflow, mention their troubles on
upstream mailing lists, or they just give up and move on.
diverging from upstream for this particular case means that on most of
those complaints, they might *also* hear "oh yeah, debian doesn't know
how to find the files from your specific installation because they
patched that out, so it's using whatever it found in $PATH". Imagine
hearing this as someone who doesn't know what $PATH is, but just
followed a recipe on stackoverflow for some other problem that stuck
arbitrary crap in your $PATH four weeks ago and then you forgot about
the whole thing. To such a user, they hear "debian broke this
package", which is not helpful to anyone.
Sophisticated users who do sophisticated debugging already have lots of
other options available to them.
> 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.
Indeed, patches welcome to automate this kind of inspection process as
part of reportbug. if that infrastructure already existed and was
well-tested, i *might* be willing to consider this divergence from
upstream after talking it over with upstream and making sure they
understand why we aim to do it, and what additional ways we plan to help
them deal with any related bug reports. As it stands, i don't think
that infrastructure exists, and i don't want to have that negotiation
with upstream.
> Secondly, I think the possibility that users may do things upstream
> consider undesirable, and even cause lossage, is precisely software
> freedom.
of course it is. I would never tell users they can't build whatever
they want to build. But i also want to support software in debian.
that means working well with upstream, managing expectations, and
minimizing the bugs that users encounter when they use the defaults.
> 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.
We clearly disagree here, though i think Ian might be overstating his
case for rhetorical effect. I'm pretty sure that Ian agrees with me
that our priorities are free software and our users, and he probably
even agrees with me that free software and our users are well-served
when distributors like Debian have good relationships with upstream, and
when most people don't *need* to fiddle with any particular piece of
software because the defaults just Do The Right Thing™ automatically.
The work involved with being a package maintainer or an upstream
developer is non-trivial, even if you only measure responding to problem
reports from users. It's not clear to me that the proposed changes
would represent any significant win to offset the increased costs in
time and energy.
For loosely-coupled software packages, where there is no expectation of
tight coupling, i'd even be fine with saying that we encourage
developers to rely on the $PATH. But banning tightly-coupled pieces of
software that are built from the same source package from remembering
and knowing where their peer components were installed in the filesystem
(which is the case for #850657 specifically) seems like unnecessary
overreach.
All the best,
--dkg
Attachment:
signature.asc
Description: PGP signature