Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts [and 2 more messages]
I see that I am Wrong On The Internet and my efforts not to distract
the TC have been futile. Sorry. Now I am falling subject to the same
problem but I really cannot let all of this go unchallenged.
Daniel Kahn Gillmor writes ("Re: Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts"):
> On Wed 2017-01-11 12:13:44 -0500, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
> > 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.
Certainly not. Our primary priority should be to make it easy for
users to make their own choices. The argument being made here is that
it should be made harder for users to make certain modifications
because that produces confusing bug reports. Outrageous!
If there were a significant risk of *users* being troubled by their
own old locally-built stuff in /usr/local, then that would be a good
argument. (For example, this might be true in the case of a program
which has an unstable command line API which means that it is not
compatible with other versions of its callers. But of course such a
thing probably wouldn't be on PATH at all.)
Sam Hartman writes ("Re: Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts"):
> I'll note that the practice of hard-coding paths is fairly common.
It is a common bug. There are many common bugs. That does not stop
them being bugs.
Of course upstream projects often do this because they need their
software to be installable in nonstandard locations and still find all
of their pieces. So such a thing is not necessarily a bug in an
upstream package. But this is not necessary in Debian packages, and
then the restriction serves no purpose.
> One common cause for this is programs that don't want to rely on PATH
> for calling exec. Systemd is a particularly interesting example.
> ExecStart and related arguments in systemd units are required to include
> full paths.
Do you really think that bringing utterly broken systemd behaviours
into this conversation would help ? It's certainly raised my blood
pressure.
Didier 'OdyX' Raboud writes ("Re: Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts"):
> Dear Ian,
> > * Say that this applies even when the program needs to find pieces of
> > the same (or closely related) package.
>
> Reading this literally (which is what the Debian Policy is for),
> this would ask the Debian project to patch literally all its
> archive. For instance, that covers literally all shebang lines.
That shebang lines don't work this way is unfortunate but I'm not
suggesting it should be changed.
> I went and read #850657, and found myself agreeing with all points
> made by Daniel: if you want a gnupg that runs your custom gpg-agent
> for debugging purposes, building a patched src:gnupg is there for
> you; we provide source for a reason.
Have you ever talked some non-Debian person through the process of
building their own patched version of some program on their
Debian-derived system ? This is not entirely straightforward, even if
they are an experienced software developer. You will find yourself
making apologies (and also missing steps out, and making false
assumptions about the reasonableness of Debian source packages).
If you think this is so easy, I would welcome patches to this tutorial
manpage:
https://manpages.debian.org/cgi-bin/man.cgi?query=dgit-user&apropos=0&sektion=0&manpath=Debian+unstable+sid&format=html&locale=en
Even though we can probably improve this (and we certainly should,
where we can), it's never going to be as easy as putting a wrapper
script on the path that invokes the subprogram with strace, or
whatever.
And it's complete overkill if what you wanted was to strace something
to see where it was going wrong (often you can't strace the parent for
some reason), or apply a ulimit, or pass a command line option that
the developers have for some reason decided shouldn't have a
corresponding config file option, or replace the program with a copy
of "true" or "false" to test the error handling, or whatever.
> All-in-all, I think that the decisions you would like the TC to
> issue would be against the project's consensus, and (which is more
> important for TC decisions) wouldn't be technically sound.
In many cases there is no way of ascertaining project consensus other
than a GR. What you see in the mailing lists is the views of those
who are loud, stubborn and thick-skinned. (FAOD a GR for this issue
would be ridiculous.)
But in this case, we can see fairly easily. We have a large body of
software written specifically by Debian contributors to be part of
Debian. We could see what that software does.
My experience is that in software writen specifically for Debian:
programs are almost universally launched from the PATH rather than by
absolute path; users are expected to put stuff in ~/bin and
/usr/local; and even in cases where an absolute path was used at some
point, filing a bug normally gets it fixed.
There is a huge gulf between Debian practice and upstream practice
here. That's not surprising, because we know so much more about the
environment and configuration in which our software runs.
> P.S. No need to reply asking me to focus on a different issue…
Your wish is my command.
To be honest, I think I'm doomed with the argument based on software
freedom. I think (to put it tactfully) that the Technical Committee
has a much narrower view of what that actually means.
The TC has consistently been very quick to defend developers' power
and slow to defend users' freedom. (I guess that's what happens when
you make a body consisting of developers.) Also there is an alarming
strand of majoritarianism.
But maybe I can use that majoritarian bias to my advantage in this
case:
Would any of you change your mind if I could do some kind of survey of
software written specifically for Debian, and report on its use of
absolute paths, vs PATH-searching ?
Or are you content with the idea that while PATH-searching is good for
our own software, when upstream do it wrong that's fine and we
shouldn't free our users from upstream's lockdown ?
Ian.
--
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.
Reply to: