Anil Madhavapeddy writes ("Bug#919951: Request about the /usr/bin/dune
filename"):
> And just to followup the query about the libdune numeric library, they
> also appear to have no plans to use /usr/bin/dune. I wasn't copied on
> their mailing list thread with the reply, but you can see it here:
1. "Appear to have no plans" is not sufficient. If we tolerate the
ocaml package taking /usr/bin/dune, then the numerics library will
probably never be able to ship /usr/bin/dune in future.
For us to be sure this is not a problem, this should be discussed with
Dune (numerics) upstream. Also, as Jö Fahlke says, the mail you are
quoting from was an internal communication. We should wait and see
what the DUNE (numerics) folks' formal position is.
2. There is still some risk of confusion over the command name, even
if there is not going to be a file conflict.
3. There is very considerable risk of confusion over the source and
binary package names.
> This seems like a reasonable solution all around. The OCaml Dune Debian
> package could also be called libocaml-dune or something, if you feel that
> `dune` is too generic a name.
I think it would be much better for it to be renamed.
> The /usr/bin/dune binary name is very very hard for us to rename,
> however, since it is so embedded in so many project Makefiles.
Insofar as the authors and users of this tool have collectively
decided to unwisely (and, I'm sorry to say, apparently also
arrogantly) adopt a short, contested, confusing project and command
name, it is right that the community surrounding that tool should bear
*all* of the costs of that decision. And if those users have lashed
themselves firmly to the mast that is not really an excuse IMO.
If DUNE (numerics) upstream can be persuaded to commit to never
shipping a binary /usr/bin/dune then I guess the situation is liveable
with. But if DUNE (numerics) upstream do not want, now, to promise
that, then that is quite understandable. In that case Debian ought to
reserve /usr/bin/dune for DUNE's possible future use.
The background here is that the Unix command namespace is a scarce
global resource. People who claim a command name have a
responsibility to choose a name in a way that considers the interests
of all the users of that command namespace.
Debian is (as far as I know) the only institution which is actually
trying to manage that namespace to ensure that everything can be
coinstalled and used together. (That of course allows people to use
Debian to make new and exciting combinations of interesting software.)
Debian should reward good behaviour and ensure that those who choose
good names, or have been using a name for a long time, do not find
someone else's tanks suddenly parked on their lawn. (Or, even,
parked at their kerb outside their house.)
Conversely Debian does *not* have a responsibility to enable, support,
excuse, or even tolerate, bad behaviour - such as choosing a command
name which the name of well-established and easily discoverable
existing software project. Indeed I would say we have a
responsibility to discourage it. At the very least someone who does
that should get short shrift whenever any kind of conflict arises.
I appreciate that this is annoying if you are on the wrong end of it.
No doubt some people make these kind of mistakes without realising
that it is Not OK to simply declare certain unrelated software
noncoinstallable.
And it is particularly annoying for the users and downstreams of
software whose upstreams are careless about these matters. But as the
user or downstream of some software you are buying into the decisions
of your upstream, for good or ill. You are buying into your
upstream's mistakes, whether those mistakes are made out of
inexperience, ignorance, haste, insularity, or arrogance.
Certainly it is not right that the other project, whose name is being
appropriated, should suffer any inconvenience.
Ian.
--
Ian Jackson <ijack...@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.
