Cross compilation: Also generate 'root'/'rootexec' sections for installation

[WardBrian]

Would close #14393. Relies on ocaml/opam#6938

In summary:
Opam 2.5.1+ will ignore any target in an .install file that starts with ../, which was previously used by dune's -x to place files in the <prefix>/<target>-sysroot directory.

To allow for this use case while preserving the security benefits of disallowing parent access, opam is considering adding root and rootexec to the .install file syntax, which I have implemented in ocaml/opam#6938

This PR updates dune to generate the new root and rootexec sections in addition to the ../.. used before. Why both? Because of the way that opam ignores things, this means that the same generated .install files would be compatibile with any opam besides 2.5.1

opam version v / .install section >	"lib" etc with ../	"root"
<2.5.1	Works as intended	Ignored (opam ignores any unrecognized fields)
2.5.1	Disabled for security	Ignored (opam ignores any unrecognized fields)
2.6.0+	Disabled for security	Works as intended

---

Update (2026-07-24):

Opam 2.5.2 was released that re-allowed .. in .install files (ocaml/opam#7009) for now.

Opam 2.6.x also allows these (github.com/ocaml/opam/pull/7008), as well as the new sections (ocaml/opam#6938) utilized by this PR

Opam 2.7.0 will disallow .. again

The approach here of generating both is still recommended, the above just buys some time...

[Alizter]

I'm less sure about duplicating install entries, why not move entirely to the new sections? AFAIK it will be dune install interpreting and acting upon this file anyway in the end?

[WardBrian]

AFAIK it will be dune install interpreting and acting upon this file anyway in the end?

In, e.g., opam-cross-windows, this was not true. As a work around, @kit-ty-kate recommended using dune install instead, but this required editing most of our opam files and some ugly hacks like actually deleting the generated .install file (which I don’t entirely understand, but was willing to accept as a hotfix)

It would be reasonable to remove the old generation after opam is released, but it’s also harmless to leave for compatibility IMO

[rgrinberg]

Are we OK with dropping support for older versions of opam here?

@toots can you comment on this feature?

[WardBrian]

Are we OK with dropping support for older versions of opam here?

To be clear, this PR does not currently drop support for older versions of opam; they will just ignore the added fields.
(apologies if you already knew that and your question was directed at other maintainers!)

[toots]

The approach is sound and with a wide backward compatibility. Thanks for working on this on both fronts @WardBrian

[rgrinberg]

Are we OK with dropping support for older versions of opam here?

To be clear, this PR does not currently drop support for older versions of opam; they will just ignore the added fields. (apologies if you already knew that and your question was directed at other maintainers!)

I did not know that. Thanks for letting me know.

However, I still think this change is essentially breaking? If we stop generating the .. paths, and start producing sections that only new versions of opam will understand, how are old users of opam supposed to cross compile?

[WardBrian]

@rgrinberg:

If we stop generating the .. paths

We don't stop generating them, which is the trick. opam ignores invalid fields in a .install file, but still processes all the valid ones in the same file. So, new opams consider the ../.. paths invalid, and ignore them, but will process prefix/prefixexec. Old opams consider the prefix/prefixexec sections invalid, but will still process the old ../.. paths

Assuming ocaml/opam#6938 is accepted before opam 2.6 is released, the only version of opam which won't accept anything in these files is 2.5.1, the current release

[WardBrian]

The other open question is if we'd like to support prefix/prefixexec in (install ...) stanzas. This PR does not currently, though it would be a minor extension.

[rgrinberg]

@WardBrian the idea itself looks good to me. Let me know when it's ready for review.

[WardBrian]

@rgrinberg I believe this is now ready for review. The main reason I was waiting was for confirmation of the name of the new field from the opam developers, and @rjbou got back to me to say they do indeed prefer root over prefix.

[rgrinberg]

So has there been an opam release with these new field names? Let's wait until there's such a release if not.

[WardBrian]

ocaml/opam#6938 has been merged. I've been told to expect an alpha release of 2.6 in the next few days

[WardBrian]

@rgrinberg I've updated the original post with more details, but to summarize:

Opam 2.6.0-alpha1 is out now, with support for the new root/rootexec sections in .install files that this PR generates
2.6.0 also allows the .. prefixes currently used by Dune, with the plan being that they will be disallowed again in opam 2.7. It is still safe to generate .install files with both directives.