Re: help with packaging deps
Hi,
On 11/06/12 17:23, Wookey wrote:
I have packaged something written in ocaml, about which I was
clueless. It's taken 18 months so far for various reasons, but is now
ready.
Yay.
Your docs:
http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.html/index.html
were very helpful. However I am left with an issue I'm not sure of the
answer to, and some residual confusion. I suspect those docs are now
slightly out of date, and quite a few refs need updating from 3.10 to
3.12.
Yes, the documentation is very outdated on various points. We really
should update it. It is mainly due to lack of time of (still) active
ocaml team members. Sorry for that :/
I have packaged the program to build native versions where compilers
are available, so following the info on this page:
http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.html/x264.html
I have done this:
OCAMLABI = $(shell ocamlc -version)
BYTECODE = $(shell [ -x /usr/bin/ocamlopt ] || echo yes)
OCAMLRUN = $(if $(BYTECODE),ocaml-base-nox-$(OCAMLABI))
...
binary-arch:
...
dh_gencontrol -- -VF:OCamlRun="$(OCAMLRUN)"
control:
Depends: ${F:OCamlRun}, ${shlibs:Depends}, ${misc:Depends}
However Lintian points out that:
E: misery: missing-dep-for-interpreter ocamlrun => ocaml-base-nox |
ocaml-base | ocaml-nox | ocaml (usr/bin/misery)
And indeed the above code only produces a build-dep an arches where
there is no native compiler. But we still need a build-dep for the
native case - right? So what are the correct deps for the native and
bytecode cases? I've read the policy several times now but am still
not sure of the answer to this question.
The dependency should not be needed for the native case (as you pointed
out in your mail later). I'm not sure what went wrong with your code
snippet though (I have to admit I didn't try to debug it (see end of my
mail)).
http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.html/x264.html
is confusing to me because it says both:
"Bytecode versions of the programs should depend on ocaml-base-nox-3.10.2"
and
"In the case where there is only one package, which provides either a
native version where available or a bytecode version otherwise, the
dependency on ocaml-base-nox-3.10.2 should be added only when the
package is built in native mode"
It is probably a typo. The last "native" should be "bytecode", IMO.
<fx: light-bulb>! I've finally understood what's going on, now that
I've written this great long mail. In fact the native version doesn't
have an install-dep because it's like a C program, but my problem was
actually that I wasn't really making one of those due to the
build-stamp/override_dh_auto_build issue documented at the bottom of
this mail, so lintian was correctly complaining about my _bytecode_
binary.
I guess the moral is to state the bleeding obvious more clearly about
required deps/build-deps as suggested below in example form, and add
the dh-compatible example to save future doc-followers from getting
horribly confused.
Agreed.
I also find this confusing despite having read it several times:
(from
http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.html/x38.html
)
"In order to build big programs and benefit from this natively built
compiler, packages should depend on ocaml-best-compilers which itself
depends on ocaml-native-compilers where available and on ocaml
elsewhere. Since it is a virtual package, it cannot (yet) be a
versioned dependency. The version dependency should thus be carried by
the ocaml dependency. Note that dependency on ocaml-best-compilers is
only necessary for real big programs for which compilation takes a lot
of resources. For most small programs the compilers from the ocaml-nox
package are perfectly sufficient, and faster to install in a build
environment than compiler executables in native code. "
Should that say "Build-depend on ocaml-best-compilers", or do you
really mean "Depends:"? There is no such package
"ocaml-best-compilers" to build-depend on, and I can't see what
provides it. (?) Despite the very thorough attempt of this doc to
explain things, and my multiple re-readings, I find I am still
confused about compilers and interpreters and package names in
ocaml-world.
It is a Build-Depends.
There are three main binaries:
- ocamlc (bytecode compiler)
- ocamlopt (native compiler)
- ocamlrun (ocaml interpreter)
ocamlc and ocamlopt are ocaml programs and they are ocaml bytecode
executables. ocaml-native-compilers ships ocamlc.opt and ocamlopt.opt
which are their native version. Building packages using .opt binaries
should be faster.
Some examples for idiots saying something like:
* packages shipping only bytecode programs:
Build-dep: foo
Depends: bar
* packages shipping both bytecode and native programs:
Build-dep: foo
Depends: bar
* package shipping native or bytecode programs, dpending on arch:
On bytecode-only arches:
Build-dep: foo
Depends: bar
On native-too arches:
Build-dep: foo2
Depends: bar2
etc.
This would cetainly help me understand.
Ack.
finally (perhaps this should have gone at the start):
the policy says:
"Programs which are not particularly CPU hungry should be compiled
into bytecode form, and the corresponding binary packages should be
Architecture: all".
How do I decide whether my package is 'particularly CPU hungry'? It
does accounting sums, and there can be quite a lot of them. But in the
examples I have this never takes an excessive time. It seemed to me
that as you'd gone to the trouble of explaining how to build that
package optimised where available, I should take advantage of that so
users get fast code where possible. So I have (and it was most
educational and I spend way too many hours getting upstream's makefile
to DTRT). However perhaps this is a complete waste of time and I
should only ship a bytecode version, which simple Build-deps and deps,
rendering much of the above questions moot. I hope not, and am
disinclined to remove all the cleverness now that it works.
If the program is used to process big data, then you should defintely
build a native version and ship it. If you feel that it may be nice but
is not necessary, then just ship a bytecode version. It is up to the
maintainer to decide given his own criteria. I personally always build
the native version when possible (it results in a faster application
with less dependencies).
The package is available here if you want to look:
http://wookware.org/software/repo/pool/main/m/misery/
Our documentation was written before dh-ocaml existed. dh-ocaml started
to compute the dependencies automatically during Debconf9. I recommend
you using it instead of the old machinery that is described in our docs.
For your convenience, I've updated your package to use dh-ocaml. You
can find the patch attached to this mail. The changes are not enormous
but provide a simpler package to maintain (and clearer debian/rules
file). Please let us know if you experience any new issues :)
Kind Regards,
--
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/
diff -Nru misery-0.2/debian/changelog misery-0.2/debian/changelog
--- misery-0.2/debian/changelog 2012-06-11 15:56:18.000000000 +0200
+++ misery-0.2/debian/changelog 2012-06-11 17:28:58.000000000 +0200
@@ -1,3 +1,10 @@
+misery (0.2-1.1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * Use dh-ocaml features.
+
+ -- Mehdi Dogguy <mehdi@debian.org> Mon, 11 Jun 2012 17:28:40 +0200
+
misery (0.2-1) unstable; urgency=low
* Initial release
diff -Nru misery-0.2/debian/control misery-0.2/debian/control
--- misery-0.2/debian/control 2012-06-11 16:04:15.000000000 +0200
+++ misery-0.2/debian/control 2012-06-11 17:26:44.000000000 +0200
@@ -2,12 +2,12 @@
Section: text
Priority: extra
Maintainer: Wookey <wookey@debian.org>
-Build-Depends: debhelper (>= 7.0.50~), ocaml-nox, xsltproc
+Build-Depends: debhelper (>= 7.0.50~), dh-ocaml (>= 0.9~), ocaml-nox, xsltproc
Standards-Version: 3.9.3
Package: misery
Architecture: any
-Depends: ${F:OCamlRun}, ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}, ${ocaml:Depends}
Description: Simple accounting package for groups, clubs, holidays
Misery is a simple way to do accounting for things like clubs, and
group holidays. Anything where you have things like shared food,
diff -Nru misery-0.2/debian/rules misery-0.2/debian/rules
--- misery-0.2/debian/rules 2012-06-11 16:46:15.000000000 +0200
+++ misery-0.2/debian/rules 2012-06-11 17:28:32.000000000 +0200
@@ -6,23 +6,18 @@
# dh-make output file, you may use that output file without restriction.
# This special exception was added by Craig Small in version 0.37 of dh-make.
-OCAMLABI = $(shell ocamlc -version)
-BYTECODE = $(shell [ -x /usr/bin/ocamlopt ] || echo yes)
-OCAMLRUN = $(if $(BYTECODE),ocaml-base-nox-$(OCAMLABI),else,ocaml-base-nox)
+include /usr/share/ocaml/ocamlvars.mk
# Uncomment this to turn on verbose mode.
export DH_VERBOSE=1
%:
- dh $@
-
-override_dh_gencontrol:
- dh_gencontrol -- -VF:OCamlRun="${OCAMLRUN}"
+ dh $@ --with ocaml
override_dh_auto_build:
dh_testdir
- if [ -x /usr/bin/ocamlopt ]; then \
- $(MAKE) opt; \
- else \
- $(MAKE) bytecode; \
- fi
\ No newline at end of file
+ifeq ($(OCAML_HAVE_OCAMLOPT),yes)
+ $(MAKE) opt
+else
+ $(MAKE) bytecode
+endif
Reply to: