Dear OCaml Maintainers,

dune-install will by default install files in the "doc" section to
$prefix/doc, this is incorrect in Debian as it should be $share/doc.

This creates problems for both users and developers.

Dune >= 2.9 allows configuring the doc install path. For previous
versions, this patch must be added:

diff --git a/src/dune_rules/install.ml b/src/dune_rules/install.ml
index afa2acdad..9fd7e6779 100644
--- a/src/dune_rules/install.ml
+++ b/src/dune_rules/install.ml
@@ -209,7 +209,7 @@ module Section = struct
       let libexec_root = libdir in
       let share_root = Path.relative destdir "share" in
       let etc_root = Path.relative destdir "etc" in
-      let doc_root = Path.relative destdir "doc" in
+      let doc_root = Path.relative share_root "doc" in
       { lib_root
       ; libexec_root
       ; share_root

Note that a similar problem may exist for files in the "etc" section.

Kind regards,
Emilio

Hello,

Le 07/09/2021 à 12:27, Emilio Jesús Gallego Arias a écrit :
opposed to "dune install" being called during Debian package builds.

Installing arbitrary software this way (with root privileges) should not
be done IMHO, but if done, it must happen in /usr/local (or outside
/usr). I remember having trouble configuring dune correctly to do that
(I couldn't tell it to "dune install" into /usr/local, but still look
for libraries in /usr/lib/ocaml in "dune build".

It would be nice if dune had a notion of "profile": a default "local"
one that would use /usr/local directories, and a "debian" one, used only
for Debian package builds, that would use $destdir/usr and $destdir/etc.
While searching for libraries in all profiles ("local" first, then
"debian").

The "correct" path for the "doc" section in the "local" profile would be
/usr/local/share/doc.

What kind of problems?

Patching things this way could (would, I think) break Debian package
builds. One has to check that all packages using dune (and there are a
lot of them now) still build with this patch. Maybe this could be done
during as part of an OCaml transition... To be continued.

I am not really sure on how to handle the "etc" section. I would use
/etc directly, even for third-party software but /usr/local/etc exists
on the Internet, so maybe it would be better to use it in the "local"
profile.


Cheers,

Hello Stéphane,

Stéphane Glondu <glondu@debian.org> writes:

I am talking about both, in particular it would be nice if

   DESTDIR=debian/tmp dune install

would install OCaml package docs in `share/doc` as opposed to `doc`,
which is the Opam layout.

This should have been solved, tho not sure in which version.

That's an interesting idea; for now, using dune 2.9, you should be able
to emulate profiles using the right options to `dune install`.

I think the idea upstream is more towards let packagers configure the
right defaults at dune build time, then have all the package builds work ok.

Indeed, so with this patch, `dune install --prefix=/usr/local` will work correctly.

Developers using

  DESTDIR=debian/tmp dune install

have to manually move doc to share/doc

Users have the problem with --prefix=/usr/local not installing the docs
in the right location.

Indeed, it could, tho actually I couldn't find a package installing the
docs as installed by dune.

I guess the etc section is fine for both uses outlined above? Maybe not
for the packaging one, as actually you'd want

 DESTDIR=debian/tmp dune install --prefix=/usr/ --etcdir=/etc

the current Dune default is the Opam layout which would install config
in /usr/etc IIANM.

Kind regards,
Emilio

Hi,

It's been a while since last activity on this bug report, I thought it
would be nice to give a status update on this matter...

In dh-ocaml 1.2.0 (released on 2023-07-15), I added an "ocaml_dune" DH
buildsystem, which takes care of calling dune with the proper arguments
during Debian package creation, and have been migrating more and more
packages to it since then.

At the moment, ocaml_dune does not specify docdir to dune, and
installation of doc into the proper location is done with other tools
from the Debian toolchain.

However, this breaks the "(package foo)" dependency specification in
Dune, see https://github.com/ocaml/dune/issues/14364

Therefore, I think the configured paths built into dune do not matter
anymore as far as Debian package building is concerned, and something
that installs into /usr/local by default could be suitable.

This is what I am planning to do to fix this bug. Any thoughts?


Cheers,