[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
ready.

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. 


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. 

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"

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

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. 

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. 


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:
http://wookware.org/software/repo/pool/main/m/misery/

Oh, and one update. The example on
http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.html/x264.html
:
build-stamp:
dh_testdir
if [ -x /usr/bin/ocamlopt ]; then \
    $(MAKE) opt; \
else \
    $(MAKE) all; \
fi

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

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 :-)

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


Reply to: