Bug#919951: Request about the /usr/bin/dune filename

[Anil Madhavapeddy]

On 23 Jan 2019, at 13:03, Jö Fahlke  wrote:
> 
> Am Mi, 23. Jan 2019, 11:59:12 + schrieb Anil Madhavapeddy:
>> - the consensus on the libdune numeric library thread is that there
>>  is no current use of /usr/bin/dune, and it can coexist fine with
>>  the OCaml dune package as a result [2]
> [...]
>> [2] 
>> https://lists.dune-project.org/pipermail/dune-devel/2019-January/002427.html
> 
> Sorry to intervene again, but I feel the state of discussion within Dune
> (numerics) upstream is misrepresented here.  While it looks currently like the
> final statement will be "Dune (ocaml) can have /usr/bin/dune and the package
> names", several of our core developers have not indicated their preference
> yet.  And one of those may well come up with a good enough argument to change
> the mind of those who already responded.
> 
> We usually assume people that don't repond don't care after about a week.  And
> we'd usually wait longer for issues such as this one which cannot be undone by
> something as simple as a "revert".  I'll try to ping the relevant people to
> speed things up.  And I (or one of the other core developers) will let you
> know here (#919951) when our discussion can be considered to have concluded.

Dear Jö,

My apologies — you raised this point in your previous reply as well. A more
accurate statement from me would have been that the *current* consensus
with Dune numerics is that there is no current use of /usr/bin/dune.  It would
of course be prudent to wait for as long as is needed for the discussion among
your developers to conclude.

regards,
Anil

Bug#919951: Request about the /usr/bin/dune filename

[Jö Fahlke]

Am Mi, 23. Jan 2019, 11:59:12 + schrieb Anil Madhavapeddy:
> - the consensus on the libdune numeric library thread is that there
>   is no current use of /usr/bin/dune, and it can coexist fine with
>   the OCaml dune package as a result [2]
[...]
> [2] 
> https://lists.dune-project.org/pipermail/dune-devel/2019-January/002427.html

Sorry to intervene again, but I feel the state of discussion within Dune
(numerics) upstream is misrepresented here.  While it looks currently like the
final statement will be "Dune (ocaml) can have /usr/bin/dune and the package
names", several of our core developers have not indicated their preference
yet.  And one of those may well come up with a good enough argument to change
the mind of those who already responded.

We usually assume people that don't repond don't care after about a week.  And
we'd usually wait longer for issues such as this one which cannot be undone by
something as simple as a "revert".  I'll try to ping the relevant people to
speed things up.  And I (or one of the other core developers) will let you
know here (#919951) when our discussion can be considered to have concluded.

Regards,
Jö.

-- 
Jorrit (Jö) Fahlke, Institute for Computational und Applied Mathematics,
University of Münster, Orleans-Ring 10, D-48149 Münster
Tel: +49 251 83 35146 Fax: +49 251 83 32729

Of all the things I've lost, I miss my mind the most.
-- Ozzy Osbourne


signature.asc
Description: PGP signature

Bug#919951: Request about the /usr/bin/dune filename

[Anil Madhavapeddy]

On 22 Jan 2019, at 19:35, Allison Randal  wrote:
> 
> On Tue, 22 Jan 2019 14:45:36 + Anil Madhavapeddy 
> wrote:
>> Dear Debian project leader (CCed), we’ve resolved the rather
>> simple technical matter in this thread amicably by directly
>> communicating with the upstream software projects involved.
> 
> Glad to hear it, that's the way it should be. :)

Dear Allison, dear all,

After some private communication with the DPL and Debian OCaml 
maintainers and your reply, the structure of the Debian Project has
been explained to me, for which I am grateful. To recap for the Technical
Committee, the state of the communicating upstreams is as follows:

- the developer of white_dune has confirmed that it is ok to rename
  /usr/bin/dune from his package to /usr/bin/wdune. He has also
  requested an update of the package as the version in Debian is
  very outdated. [1]

- the consensus on the libdune numeric library thread is that there
  is no current use of /usr/bin/dune, and it can coexist fine with
  the OCaml dune package as a result [2]

- OCaml Dune is happy to make whatever documentation or
  packaging changes necessary to avoid any confusion to users.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919951#37
[2] https://lists.dune-project.org/pipermail/dune-devel/2019-January/002427.html

>> If he *doesn't* speak for Debian, then we’d love to be able to
>> directly speak to whoever resolves these matters so that the
>> hardworking Debian package maintainer for OCaml can get
>> on with his volunteer efforts without being harassed by Ian Jackson.
> 
> As with many open source projects, Debian is a collection of volunteers
> who each represent the project in various ways in the course of their
> day-to-day contributions. We tend to be egalitarian, and while we have
> governing bodies and a project leader, those are more of a last resort
> when we can't sort things out any other way. Ian can speak for the
> Debian project at times (as may any Debian Developer), but most of the
> time he is expressing his own personal opinion. He is a long-term member
> of the Debian project, and we greatly respect his opinion. But, even he
> freely admits that he sometimes speaks more acerbically than the
> situation merits.

Thanks also for this clarification, Allison. My concerns arose from
a combination of the perceived authority with which Ian Jackson spoke,
his invocation of important-looking procedural matters within Debian,
and the rather absolutist and antiquated position from which he
debated the point.

It can be easy to forget that we as experienced OSS developers are
no longer FTPing up tarballs to Sunsite and excitedly updating the
Freshmeat.net  entry with a new release.  Our respective 
projects
(OCaml and Debian) now represent the work of hundreds, if not
thousands of developers' contributions, and the costs associated
with putting those contributions at jeopardy are high.

It is also why Ian's absolutist position that ascribed ill-intentions
and negligence to the OCaml community is so wrong. In the "good
old days", a developer could reasonably track a global namespace,
but nowadays there are thousands of OCaml packages in our domain
specific package manager alone.  From these, we cannot predict
which ones will succeed and be worthy of packaging as first-class
entities in Debian.  A file search in the Debian namespace is
insufficient: it will not reveal potential conflicts from (e.g.) another
fast growing projects in Cargo or Npm, or policy decisions taken
by other distributions that cause conflicts in Fedora, Arch or
OpenSUSE (for which we also maintain CI and container images)

So the best we can hope for in modern OSS packaging is for
the upstreams to be as cooperative as possible with each other, and
for Debian to facilitate such communication. As such, this has
happened very effectively here, and Debian is providing a valuable
service for which we are grateful.  My ire emerged solely from the fact
that we appeared to being forced to have this conversation while
being held hostage, which is unnecessary and risks the trust of
all those developers for whom we are responsible downstream to
that use OCaml and Debian together.

Thanks again for all the helpful feedback, and I look forward to
making future contributions to Debian now that I understand the
project much better.  I have a prototype executable linker/loader
lying around that hides multiple binaries using cgroups/unshare
so that naming conflicts can be handled cleanly. Good fodder for
a future Cambridge pub conversation :-)

regards,
Anil

Bug#919951: Request about the /usr/bin/dune filename

[Allison Randal]

On Tue, 22 Jan 2019 14:45:36 + Anil Madhavapeddy 
wrote:
> Dear Debian project leader (CCed), we’ve resolved the rather
> simple technical matter in this thread amicably by directly
> communicating with the upstream software projects involved.

Glad to hear it, that's the way it should be. :)

> However, there are lots of references to what Debian ‘should’
> and ‘must’ do in the above quoted email, but very little clarity on
> Ian Jackson’s actual authority to speak for Debian.  Who is he,
> and is he speaking for the Debian project (with insults and all)?
> He appears to have resigned from the Debian Technical Committee
> some years back, but I am not familiar with the internal structure
> of your project.
[...]
> If he *doesn't* speak for Debian, then we’d love to be able to
> directly speak to whoever resolves these matters so that the
> hardworking Debian package maintainer for OCaml can get
> on with his volunteer efforts without being harassed by Ian Jackson.

As with many open source projects, Debian is a collection of volunteers
who each represent the project in various ways in the course of their
day-to-day contributions. We tend to be egalitarian, and while we have
governing bodies and a project leader, those are more of a last resort
when we can't sort things out any other way. Ian can speak for the
Debian project at times (as may any Debian Developer), but most of the
time he is expressing his own personal opinion. He is a long-term member
of the Debian project, and we greatly respect his opinion. But, even he
freely admits that he sometimes speaks more acerbically than the
situation merits.

> I hope that’s clear enough.

Same here, but if it's not, I'm happy to pop over to your office two
doors down to explain further. :)

Allison

Bug#919951: Request about the /usr/bin/dune filename

[Anil Madhavapeddy]

On 22 Jan 2019, at 11:46, Ian Jackson  wrote:
> 
> 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.

While you were making unsubstantiated comments about myself and 
Jeremie, we simply contacted the other projects to have a civilised
conversation.  For the record, the thread has continued and more libdune
developers have indicated that they have no intention of using this binary:

https://lists.dune-project.org/pipermail/dune-devel/2019-January/002426.html

>> 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.

As an outsider to Debian, I have to ask some basic questions
(CC lea...@debian.org).

Ian Jackson keeps repeatedly accusing us via terms such as
‘unwise’ and ‘arrogant’, while carefully avoiding commenting
on the rationale for our choices. I would note that we are unable
to predict which of our open source projects will succeed and be
worthy of inclusion into Debian ahead of time, and so it is difficult
to always pick names that are fresh and unique globally.

Dune is one such example — we have already posted our rationale
for our choice (and indeed, the discussions with Whitedune and
libdune have all been resolved amicably and very quickly).
There are only so many times that I can post this before I get tired
of Ian Jackson calling me names with the Internet equivalent of his
spittle raining down on my face.

> In that case Debian ought to reserve /usr/bin/dune for DUNE’s
> possible future use.
> 
> 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.

Dear Debian project leader (CCed), we’ve resolved the rather
simple technical matter in this thread amicably by directly
communicating with the upstream software projects involved.

However, there are lots of references to what Debian ‘should’
and ‘must’ do in the above quoted email, but very little clarity on
Ian Jackson’s actual authority to speak for Debian.  Who is he,
and is he speaking for the Debian project (with insults and all)?
He appears to have resigned from the Debian Technical Committee
some years back, but I am not familiar with the internal structure
of your project.

If he *does* speak for the project and no apology or response is
forthcoming, then we (ocaml.org) will be reconsidering our support
in terms of CI and infrastructure investment in testing and supporting
Debian.  Life’s too short to work for free on open source software in
return for insults on the Internet.

If he *doesn't* speak for Debian, then we’d love to be able to
directly speak to whoever resolves these matters so that the
hardworking Debian package maintainer for OCaml can get
on with his volunteer efforts without being harassed by Ian Jackson.

I hope that’s clear enough.

regards,
Anil

Bug#919951: Request about the /usr/bin/dune filename

[Ian Jackson]

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 JacksonThese 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.

Bug#919951: Request about the /usr/bin/dune filename

[Jö Fahlke]

Am Mo, 21. Jan 2019, 20:00:18 + schrieb Anil Madhavapeddy:
> 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:
> 
> https://lists.dune-project.org/pipermail/dune-devel/2019-January/002422.html
> 
> Ansgar Burchardt wrote:
> > I don't think DUNE (the numerics framework) will ship /usr/bin/dune.
> > I thought about introducing a "dune" meta-package that would depend
> > on all DUNE modules available in Debian, but that could just be called
> > "libdune" instead; that way it would sort close to the other libdune-*
> > packages.

Sorry, but I have to stop people from jumping to conclusions here.  Ansgar's
statement was meant for discussion within Dune (numerics), if I'm not
mistaken.  We were made aware of this problem only today, please give the
other Dune (numerics) developers a few days to form an opinion and to react.

Regards,
Jö.

-- 
Jorrit (Jö) Fahlke, Institute for Computational und Applied Mathematics,
University of Münster, Orleans-Ring 10, D-48149 Münster
Tel: +49 251 83 35146 Fax: +49 251 83 32729



signature.asc
Description: PGP signature

Bug#919951: Request about the /usr/bin/dune filename

[Anil Madhavapeddy]

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:

https://lists.dune-project.org/pipermail/dune-devel/2019-January/002422.html

Ansgar Burchardt wrote:
> I don't think DUNE (the numerics framework) will ship /usr/bin/dune.
> I thought about introducing a "dune" meta-package that would depend
> on all DUNE modules available in Debian, but that could just be called
> "libdune" instead; that way it would sort close to the other libdune-*
> packages.

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. 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.

regards,
Anil

Bug#919951: Request about the /usr/bin/dune filename

[Anil Madhavapeddy]

On 21 Jan 2019, at 16:55, J. Scheurich  wrote:
> 
> Dear developer of white_dune,
>> I am the original author of the dune build system [1] for the OCaml
>> language. I'm writing to you as I have recently been made aware that
>> there is a conflict in Debian over the filename /usr/bin/dune. Indeed,
>> /usr/bin/dune is currently used by the white_dune package. As a
>> result, our software which also installs a binary called "dune" cannot
>> be added to Debian.
> 
> Unfortunatley, i have no control over the debian build.
> Debian still ships version 0.31 while version 0.99pl280 is recent.
> I asked for years to update it, no luck 8-(
>> Given that our software is a command line tool, the name of the tool
>> is extremely important to us.
> 
> white_dune can also be used on the commandline (for conversion
> to RIB, C. c++, java from to X3D/XML ...).
> 
>> So I was wondering if you would be
>> willing to let us use the name /usr/bin/dune and only use
>> /usr/bin/white_dune for your white_dune software?
> 
> Better /usr/bin/wdune, this is the short form of white_dune.
> 
> "dune" is very popular as a name, there is also a numerical
> program:
> 
> https://www.dune-project.org/
> 
> white_dune started as "dune" by Stephen F. White
> 
> https://sourceforge.net/projects/dune/
> 
> As i forked it, i changed the name to "white_dune"

Thank you very much indeed for the quick response!

I am copying the Debian developers on bug #919951: this is
OCaml and white_dune coming to an agreement that /usr/bin/wdune is
an acceptable binary for white_dune, and /usr/bin/dune for the
OCaml tool.  The packages can therefore coexist.

Please also note the white_dune maintainer’s long-standing
request for white_dune version 0.31 to be updated to 0.99pl280
in the package.

regards,
Anil