Support etc_root and etcexec_root in opam-installer

[hongchangwu]

Use case

Startup scripts for Linux system daemons are traditionally installed under /etc/init.d.

[AltGr]

Not really sure where this would be useful: it would basically allow to write to /usr/etc (or ~/.opam/some-switch/etc, even) rather than /etc ?

[hongchangwu]

It's the same contrast between share and share_root.

With the current etc variable files can be only installed under e.g. /usr/etc/<package name>, but not under /usr/etc/ or /usr/etc/init.d.

[rjbou]

What is you use case ? By default, opam won't install to root directories, but on its the switch prefix (cf. etc_dir definition)

[dra27]

Note that PR’s concern seems to be about opam-installer rather than opam

[hongchangwu]

Hi, the purpose of this PR is not to install to root directories, but rather to be able install things under <prefix>/etc/ directory (etc install things under <prefix>/etc/<package name> )

The use case is stated in the PR description: Linux system daemon scripts are traditionally installed under <prefix>/etc/init.d. Currently AFAIK there is no way to do that with opam-installer. Even hacks such as using ../ in the path does not work because anything installed under etc will not be executable, and the scripts under <prefix>/etc/init.d need to be executable.

BTW this PR (https://github.com/ocaml/opam/pull/1141) introduced share_root to address a similar issue.

[hongchangwu]

@dra27 right, opam doesn't install to system directories, but it's perfectly conceivable for system package managers such as debian to use opam-installer when packaging OCaml things. As such it would be good if opam-installer is able to support install system startup scripts under <prefix>/etc/init.d.

[hongchangwu]

@rjbou thanks for the reply. I'll take a look at this soon.

[rjbou]

ping @hongchangwu

[rgrinberg]

A year later, ping @hongchangwu :)

[toots]

Hi there! Would love to see this merged as well. We could definitely use it for liquidsoap. There's a corresponding PR for dune here: https://github.com/ocaml/dune/pull/4077

[rjbou]

updated

[dra27]

At this stage, this obviously isn't going to be in 2.1, but there are a couple of things which need to be considered. It should be an error to have these fields in a file headed "opam-version: 2.0" and we should also ensure that when writing these files opam only uses opam-version: "2.1" if there are etc_root and etcexec_root fields to write.

[hongchangwu]

Apologies for not responding earlier, this has fallen off my radar. Yeah I think it will be nice to support this. I can update the PR.

[hongchangwu]

Rebased.

[dra27]

Thanks, @hongchangwu! We still need to address what to do about opam-version and ensuring that these fields are an error if opam-version: "2.0" was encountered. We're just in the process of getting opam 2.1 to release candidate, but I've put this PR in the 2.2.0~alpha milestone to ensure it gets remembered.

[dra27]

This PR is definitely still remembered! The machinery for validating fields by version (i.e. rejecting etc_root in foo.install if it has opam-version: "2.0") is likely to be added as part of the opam file rewriting plugin, and once that's in it would unblock the ability to merge this.

[dra27]

We're not looking at file format changes in 2.2, so bumping this for consideration in 2.3

[maxim092001]

Hi, just wanted to ensure that this PR won't get lost. I opened an issue https://github.com/ocaml/opam/issues/6014 that this PR would solve couple of years ago.

Is there anything community can help to get in merged?