Bug#357634: Please add mips/mipsel (and others) to control (or make it "any")
On Sat, Mar 18, 2006 at 07:43:30PM +0000, Martin Michlmayr wrote:
> * Sven Luther <email@example.com> [2006-03-18 20:25]:
> > There is no native ocaml compiler for mips/mipsel, and as thus, there is no
> > need for mips/mipsel to build the native-code spamoracle package.
> So why does the package use ocaml-nox rather than
> ocaml-native-compilers to compile the native-code package?
Because the ocaml-native-compilers contain the native-compiler built version
of the bytecode and native code compilers, while ocaml-nox, contains the exact
same ones, but built as bytecode, so they are a bit slower for really big
projects like coq. On the plus side they are lighter to load into memory i
> If ocaml-nox can build this package, shouldn't the native-code
> spamoracle package. be built on all arches that have ocaml-nox? Or
> should the build-dependency be ocaml-native-compilers instead?
Nope, because ocaml-nox has ocamlc (the bytecode compiler) for every arch, and
ocamlopt (the native code compiler) on those arches supporting native
The ocaml-native-compilers are only the optimized versions of the previous
(ocamlc.opt, ocamlopt.opt) and produce the exact same result (bit-to-bit equal
> > should be pretty obvious from the description of the spamoracle and
> > spamoracle-byte packages.
> As somehow who doesn't know ocaml at all, this is not obvious at all.
> Looking at the build-dependency suggests only ocaml-nox is needed, and
> that is available on mips.
There is an ocaml policy document, which explains all this in more or less
But the ocaml packaging and build process has been thoughtfully designed, and
is the result of 8 years of refinement in packaging technology, designed and
reviewed by a team of very brillant people even, not just me, so, in most
cases, if you think there is an obvious bug such as this one, 9 chances out of
10, you simply misunderstood the issue :).
> > > > Automatic build of spamoracle_1.4-7 on bigsur by sbuild/mips 1.94
> > I guess you should just fix the buildds to not try to build packages they have
> > no business messing with.
> This is not an official buildd.
Ah, well, you should fix it not to try to build empty packages then :)