[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: cmdliner 1.0.0 uses topkg for building



On 18/07/2017 15:11, Daniel Bünzli wrote:
As for automation, it remains to be seen whether we want to map 1 opam package to 1 Debian
package, or to map 1 git repo containing many opam packages to 1 Debian package. The downside
of the first approach is similar to the above points. Also the overhead of Debian packaging
is more than opam packaging (it takes care of more things) so if people want to do left-pad
in ocaml it might be better to group those together in Debian. The second approach would
be easy to automate in the case that whole-git-repos do not form cyclic dependencies
with other whole-git-repos.

I don't understand why you are talking about git repos. Tarballs are the source of releases. I'm not a debian packager but I also see a lot of packages in debian itself that I presume are based on the same tarballs (e.g. dev and non-dev) packages.

In Debian, we have the notion of "source packages" (upstream tarball + debian directory) and "binary packages" (.deb files). The compilation of one source package produces one or several binary packages. What you see with dev and non-dev packages is two binary packages generated by the same source package and indeed it is very common.

For topkg and topkg-care, we would need two source packages with the same tarball, which is not common in Debian (I don't know if it even exists) and was what was bothering Hendrik. In my own opinion, it's fine.

- If you release {tokpg,topkg-care} v0.8 then v0.9, but in v0.9 topkg-care actually
did not change at all and was exactly the same as in v0.8, this makes it harder to resolve
dependencies. Something that uses topkg-care >= v0.9 can actually be satisified by
v0.8, but opam wouldn't know this.

You are trying to make things more complex than they are here. topkg and topkg-care must always be used with identical versions. This is enforced in the opam files which are machine readable and from which you can infer your constraints.

Lockstep upgrades are frowned upon in general in Debian, but of course they are supported. In the specific case of topkg and topkg-care, I don't think there would be any practical problem.


Cheers,

--
Stéphane


Reply to: