Re: Depends clause of control
On Sun, Aug 27, 2006 at 03:24:05AM +1000, skaller wrote:
> 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.
This is not what is prefered for debian package, since using -custom means
that you cannot reuse the same bytecode binaries on different arches, and thus
end with a lot of identic and duplicate packages in debian, imposes an
additional loads on the non-native arches autobuilder, and since those are
usually the slowers, you may also get hit by buildd-lag and stuff like that.
> The Policy, instead of frowning on -custom, should
> provide guidance on how to make this choice.
It provides guidance, and the reason for that choice was done after years of
experience and discussion. See load of threads on this mailing list over the
years.
And again, in your case, look at spamoracle package for guidance.
> 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.
The only reason to keep -custom, is in cases like advi, where you have C
bindings which you can't or won't move into their own library, and thus you
have to do -custom anyway.
The ABI change is not all that important, since the ocaml debian team is
usually rather quick and experienced in how to handle this, and it can be
automated upto a point, as was the case for the last set of ABI upgrades,
where Steve Langasek simply triggered a bunch of binary NMUs.
> 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]
Cool, please keep it so.
> 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.
The dependency on the right version of ocaml-base-nox provides you with a
stable abi, since we include an abi number in that versioned virtual package
name. Again, please read past posts about this.
> Perhaps I misunderstand but there is NO reason this should cause
> any bloat. All that is required is a dummy executable which
Notice that we speak of archive bloat, this is here the debian archive, since
you need multiple copies of the same bytecode for all non-native code arches,
and buildd time, and dependency on slower machines, and possible toolchain
hazards, or problems due to the buildd admin going offline and not signing
packages, and what else.
> 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).
Indeed.
> 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.
Different definition of bloat :)
> Is this a problem with Inria not actually doing that?
Nothing such.
Friendly,
Sven Luther
Reply to: