Re: ocamlopt issue

[Sven Luther <luther@lambda.u-strasbg.fr>]

On Thu, Jun 27, 2002 at 08:07:52PM +0200, Ralf Treinen wrote:
> On Thu, Jun 27, 2002 at 02:14:49PM +0200, Stefano Zacchiroli wrote:
> 
> > Yes, this is the right choice.
> > IIRC Ralf's solution will inhibit ocamlsdl from entering testing due to
> > missing package build dependencies.
> 
> I don't think that missing *build* dependencies will stop a package to go into testing (in
> contrast to simple dependencies).

Well, yes, i think it will.

Let's explain, it is not the missing build dependencies that will stop the
package from entering testing.

But, if the missing build depend is a true build depend, then the
package cannot be build without it, and the autobuilder will fail to
build the package, and then the missing binary package on all the
supported arches will stop the package from entering testing.

Now, if the package can be built without this build dependency being
stated, then something is wrong, and maybe it is not a true build
dependency.

Well, it is not written in the debian/ocaml packaging policy, but i
would strongly suggest this course (and i will add it to the next policy
document unless someone disagrees strongly) :

 o each executable package should be able to easily be built with both the
   native code compiler and the bytecode compiler.

 o each library package should build both the bytecode and the
   nativecode library.
 
 o in all cases, the package should depend on ocaml and/or ocaml-base,
   and have an explicit test to check if the ocamlopt compiler is
   present, and build the native code stuff only in the case where it is
   present, instead of the bytecode version for the executable packages,
   and in adition to the bytecode version for the library packages.

I don't believe it is ok for a package to be limited to the arches that
support the native code compilers, as there is no reason (that i know
of, but i may be wrong) that the package should not build with the
bytecode compiler, apart from the short sightedness from the upstream
authors.

Packages who do not check for native code support and fall back to
bytecode are buggy package and should be threated as such (well either
fixed or reported to upstream, but mostly the fix is trivial).

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org