I’m maintaining an OPAM external repository for our package, say package A. The package A requires package B as dependency. We use a fork version of B version 0.1, named version “0.1+a”. The package B 0.1+a is distributed by our own OPAM repository.
A 1.0 <-- B 0.1+a
The forked version of B is highly developed. But its version string can’t be changed from “0.1+a” because it’s still a fork of the original B 0.1.
This causes a problem when rebuilding A after an update of the forked version of B. It needs a manual update of B because OPAM doesn’t understand the update.
opam reinstall b
So my question is: how to manage updates of our forked packages with OPAM? Is there any standard ways to deal with this problem?
If I understood correctly you would like an automatic way to rebuild A and B. Unless you are pinning the packags, to have an auto update, you should internally release new versions, like 0.1+b and then 0.1+c and so on, and at that point running opam update and then opam upgrade would build and reinstall the right packages. Note also that the opam package of B needs to expkicitly list its dependency on A.
@mseri Thanks for your reply. I mean “forked version of 0.1 for package A” by “0.1+a”, so I will use “0.1+a.1”, “0.1+a.2”, or something if I use your method. Or, it’ll be also OK to use vgo’s format such as “0.1+a.yyyymmddhhmmss.commit”.
Is this format OPAM-ish? I haven’t seen such complex version strings…
See @dbuenzli reply. But if you use them internally then you can pick either of them, I think they should be fine as long as they are incremental with respect to the opam definition of incremental
