Hello, Le 06/03/2025 à 20:19, Samuel Thibault a écrit :
The attached patch adds a pkg.ocaml-topkg.noopam build profile which can be used to avoid using opam-installer and still build a proper libtopkg-ocaml-dev package, could you apply it?
I don't really like your patch. It installs more files, and with different permissions. It looks fragile: it can break silently if something changes upstream.
I would rather see some generated scripts (à la autotools), put them in the source package, try to regenerate them at install time if possible, and run them.
opam-installer does have a --script option but it cannot be used as is because the generated script depends on the architecture: on OCAML_STDLIB_DIR (which includes multiarch) on one hand, on whether the architecture is native or bytecode on the other hand (the list of files changes) on the other hand.
I've implemented something using opam-file-format that should work everywhere, break on unexpected upstream changes, and produce identical binary packages whether the build profile is set or not. I will upload it soon.
Cheers, -- Stéphane
