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

help with packaging deps

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

Your docs:
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

I have packaged the program to build native versions where compilers
are available, so following the info on this page: 

I have done this:
OCAMLABI = $(shell ocamlc -version)
BYTECODE = $(shell [ -x /usr/bin/ocamlopt ] || echo yes)
OCAMLRUN = $(if $(BYTECODE),ocaml-base-nox-$(OCAMLABI))
dh_gencontrol -- -VF:OCamlRun="$(OCAMLRUN)"

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. 

is confusing to me because it says both:
"Bytecode versions of the programs should depend on ocaml-base-nox-3.10.2"
"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"

Why aren't these contradictory? Do we need an ABI-specific dep for the
bytecode stuff or the native stuff or both?

<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_

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.

I also find this confusing despite having read it several times:

"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

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


This would cetainly help me understand. 

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.

The package is available here if you want to look:

Oh, and one update. The example on
if [ -x /usr/bin/ocamlopt ]; then \
    $(MAKE) opt; \
else \
    $(MAKE) all; \

needs to change for use with dh, to :
f [ -x /usr/bin/ocamlopt ]; then \
    $(MAKE) opt; \
else \
    $(MAKE) all; \

otherwise you only ever get whichever target 'opt' or 'all' is first in
the makefile built.

So, after all that I think it's all correct now, unless someone wants
to tell me it isn't :-)

Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM

Reply to: