Re: Depends clause of control
On Sat, 2006-08-26 at 16:32 +0200, Samuel Mimram wrote:
> Here is how it has been done in the mldonkey package:
>
> * in the debian/control file:
>
> Package: mldonkey-server
> Architecture: any
> Depends: ${shlibs:Depends}, ${interpreter:Depends}, ...
>
> * in the binary-arch target of the debian/rules:
>
> if [ -e /usr/bin/ocamlopt ]; then \
> echo "interpreter:Depends=" >> debian/mldonkey-server.substvars; \
> dh_strip; \
> else \
> echo "interpreter:Depends=ocaml-base-nox-$(OCAMLABI)" >>
> debian/mldonkey-server.substvars; \
> fi
>
> > I mean .. it certainly is possible, could this technique
> > be fixed and put in the policy document?
>
> Yes, I guess we should improve the policy on this point.
Well I like Eric Coopers version slightly better:
------------------------------------------
debian/control:
Depends: ${shlibs:Depends}, ${F:OCamlRun}, adduser, bzip2, curl
debian/rules:
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)"
------------------------------------------
because it looks a bit simpler and I'm stupid :)
It would indeed be nice if this was written up in
the Policy, to avoid errors reinventing the wheel.
------------------------------------------------
I'd ALSO like to see the use of -custom bytecode
permitted, for certain packages, but I may misunderstand
what it does!
The reason is that it emulates the behaviour
of native code, in particular,
* it isn't sensitive to ABI changes.
* it is sensitive to processor (CPU) changes
Each kind of portability -- insensitive to ABI or
insensitive to CPU -- is useful. Whilst Ocaml
continues to provide a new ABI each patch,
there should be a choice .. IMHO.
The Policy, instead of frowning on -custom, should
provide guidance on how to make this choice.
For example: for 'felix' package, the small cost of
extra space due to binding isn't really important.
Since we prefer native code anyhow .. which is bloated compared
to bytecode, and already won't port to different CPUs.
the -custom option probably makes more sense.
OTOH a web service providing dynamic loading of bytecode
is using bytecode to allow Dynlink to work: ocamlc is
already required, not just ocamlrun. So for such a package,
using -custom would be the wrong choice .. and indeed it
might actually break the system.
[BTW: felix does NOT use -custom at the moment]
Actually I'm confused: here we have:
"All bytecode executables should be linked dynamically against the
shared libraries for C bindings, so as to not bloat the archive. That
said, often the upstream authors will favor statically linked bytecode
executables, because so they don't need to worry about the presence of
the dll stub libraries and such. This is not a valid reason to use
statically linked bytecode in a Debian package."
I have no problem with dynamic linking here: the problem is with
binding the bytecode to the correct runtime interpreter: the linkage
to the libraries is controlled by ELF which handles multiple versions
without any problems. Perhaps I'm confused.. I'm not after static
linkage, but statically binding to ocamlrun with the right ABI.
Perhaps I misunderstand but there is NO reason this should cause
any bloat. All that is required is a dummy executable which
includes the bytecode in a magic place, which executes ocaml
run interpreter. There's no reason that interpreter shouldn't
be provided in a shared library. Elf will automatically use
the correct shared library for the bytecode (provided of
course the library is properly versioned).
There is no bloat from this model .. we're talking a couple of
lines of code to find the bytecode and call a shared lib,
passing the bytecode address.
Is this a problem with Inria not actually doing that?
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
Reply to: