Re: cmdliner 1.0.0 uses topkg for building
Daniel Bünzli:
> On 18 July 2017 at 10:42:51, Hendrik Tews (hendrik@askra.de) wrote:
>
>> Preparing Debian packages would of course be much more straightforward, if topkg and
>> topkg-care would not share the same source tarball ;-)
>
> I am a bit curious on why this is the case exactly. What kind of difficulties does it specifically bring ?
>
In Debian they have to go in two separate source packages, because the distributed nature of package building means (if it were in a single source package) we can't run the build for topkg, run the build for cmdliner (another package), then run the build for topkg-care. Then, maintenance of two identical source packages requires more work than maintaining two different source packages:
- for developers, to figure out which files "actually belong" to a particular package, in the cases where you'd like to install them to places that opam doesn't yet cover.
- for users and reviewers, to figure out why certain files are being ignored as part of the build
- bug reports that affect the source package (such as metadata), may or may not have to be duplicated to both packages.
- if the package has to be patched for urgent bugfixes or security fixes, the person handling this has to figure out whether they have to patch both packages or just one. (assuming the patch is in the form of commit(s) to the whole git repo.) patching both packages and re-uploading them and rebuilding its dependent packages involves more work, so it's not just a "might as well patch both" situation.
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. It would not be easy to automate in the case of topkg. In general, ignoring opam and Debian packages altogether, one does not usually see build instructions like "run ./configure, run make partA, git clone project Y, cd Y && make && cd .., run make partB, etc etc".
The shared version history can make things harder to upgrade.
- 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.
- Depending on the situation we might be forced to upgrade cmdliner at the same time, e.g. if topkg-care 0.9 depends on cmdliner >= 1.2, topkg = 0.9, then we would be forced to upgrade cmdliner when upgrading topkg to v0.9, and everything else that can't use an older cmdliner. If the versions were split, we could upgrade topkg 0.9 independently of topkg-care. Of course in many cases there is no problem, but in specific cases it causes pain. If you like, you can make topkg-care 0.9 depend on >= topkg 0.9 instead of = 0.9, then you can take on the burden of tracking the compatibility yourself as the version numbers increase. I suggested that it would be easier to do this, if the version number of topkg-care was a totally different number from topkg, but you seem not to have read that part of what I wrote.
I could construct more examples by spending more time, but they all point to the general principle that this sort of arrangement is really not worth it. On your side, what do you think you gain from it?
> In any case I suspect packaging topkg-care is not going to be useful as it is a tool to help with the bureaucracy of making and distributing releases and submitting them to the OCaml opam respository (see e.g. here [1] for a high-level description). [..]
I also recommended (in a previous email) ignoring topkg-care for the time being in Debian. I'm glad you agree with this approach.
> More generally. Always feel free to ping me in when you encounter difficulties packaging my software. Besides we are keen in general in hearing more about system packagers and their needs on the ocaml platform mailing list [2] or whichever medium you may find fitting, opam or OCaml opam repository issue tracker or discuss.opam.org or the ocaml mailing list.
>
> [..]
Would you like to provide us with a list of your "trigger phrases" such as "circular dependency" and "intuition" that cause you to completely shut down, assume the person writing it is "out to get you", and go into panic-defense-mode?
X
--
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git
Reply to: