If you’re thinking about the RPM model that a given source package should emit the same binary version, then the best way to model the version number of a package is the concatenation of all its dependent package names and versions. You could hash the result in order to have a non-monotonic version string that is suitable for creating RPMs from (upstream Fedora/OCaml adopts a similar approach)).
I would like to improve this though. The forthcoming Dune 1.10 will have the facility to store opam metadata inside the
dune-project file and generate the opam files. Part of the reason motivating this feature was to reduce the amount of boilerplate in a dune/opam project, but the other reason I started it was to improve the RPM/Deb packaging situation.
When all OCaml project dependencies are in a duniverse. it should be possible to generate RPM/Deb files that have accurately upgraded monotonic version numbers for their individual binary packages. We would have to do this by fine-grained analysis of all the constituent dependencies of a given opam package, but of course dune has this information as part of the build process. My intention is to make this upstreamable – that is, we should be able to generate an Ubuntu PPA from the bulk of OCaml source code in opam, with accurately incrementing source epoch numbers such that OS package manager upgrades work.
There are a few other features awaiting implementation into dune/opam before this will really work end-to-end. @rjbou is working on integrating the depext plugin into opam 2.1, and I’ve got a spec I’m writing for adding that field into dune-project as well.