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

Re: RFS: ocaml-migrate-parsetree



Hi Andy, sorry for the delay.

Andy Li:
>  [..]
> 
> There are a number of things that I'm not sure:
> 
>  * When I try to use dh_ocamldoc, there is an error processing
> migrate_parsetree_versions.mli, which contains OCaml_OCAML_VERSION,
> which should be replaced by a preprocessor in some way. I want to
> exclude it from ocamldoc, but turn out the dh_ocamldoc "-X" option
> wouldn't work. So, I copied the whole ocamldoc command into
> override_dh_ocamldoc.
> 

I think it is (slightly) more future-proof if you do this instead:

debian/preprocess-ocamldoc.sh:
    echo '#!/bin/sh' > "$@"
    echo 'sed -e "s/OCaml_OCAML_VERSION/OCaml_$(shell echo $(OCAML_ABI) | cut -d. -f1-2 | tr -d .)/g" "$$@"' >> "$@"
    chmod +x "$@"

override_dh_ocamldoc: debian/preprocess-ocamldoc.sh
    dh_ocamldoc -u "-pp $<"

It creates a script to do the actual preprocessing so we get a complete set of docs. (Yes I know PP is deprecated, but ocamldoc still supports it..)

More generally, it looks like jbuilder expects to use odoc instead of ocamldoc - then one can do "jbuilder make @doc". But unfortunately this is not in Debian yet. Perhaps you/someone else could package it later, if you have time?

>  * The license should be LGPL2.1 with linking exception - I'm not sure
> if I describe it correctly in d/copyright.
> 

Slightly unfortunately, d/copyright needs to be self-contained except for references to /usr/share/common-licenses. So you need to c+p the text from LICENSE into d/copyright.

>  * There is an ocamlbuild plugin package built from this source
> package, I'm not sure the naming,
> libmigrate-parsetree-ocamlbuild-ocaml, is correct or not.
> 

Since the upstream README.md refers to it as ocaml-migrate-parsetree-ocamlbuild, then yes your name is correct according to the existing ocaml packaging naming conventions.

But if ocaml-migrate-parsetree already depends on ocaml-migrate-parsetree-ocamlbuild (or the other way around), then TBH personally I think it would be better to combine both into the same Debian package. We don't need to split things up too much, these packages are tiny, and this type of micro-split is not worth the metadata overhead cost on the archive, on user machines, and on maintainers. It's up to you though, since you are the maintainer.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git


Reply to: