[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Depends clause of control

On Sun, Aug 27, 2006 at 04:47:17AM +1000, skaller wrote:
> On Sat, 2006-08-26 at 20:26 +0200, Sven Luther wrote:
> > On Sat, Aug 26, 2006 at 08:00:22PM +1000, skaller wrote:
> > > I have a package which says this:
> > > 
> > > Depends: ${shlibs:Depends}, g++, ocaml-nox-${F:OCamlABI}
> > > 
> > > however this is wrong. If the arch supports native
> > > code compiler, there is no dependency on Ocaml at all.
> > > If the arch only supports bytecode, then ocaml_run is required
> > 
> > If this is the case effectively, then have a look at the spamoracle package,
> > which is the canonical example on how to package a bytecode/native code
> > package.
> > 
> > Basically, you generate a arch: all bytecode package and a arch: <list of
> > native arches> native package.
> > 
> > This way, you generate the bytecode package only once, and both the bytecode
> > and the native code version is available on all arches which support native
> > code, and the native code version is also prefered over the bytecode one.
> However, wouldn't this only work if the package consisted ONLY
> of a single executable?

Nope, it will work as long as either all the content is non-custom bytecode,
or if the non-bytecode stuff can be factored in a separate binary package.

> Felix doesn't meet that condition. If the package was
> 'properly' factored it could meet that requirement, but at
> this time it isn't: it also includes other stuff including
> C++ code which is built into libraries and executables,
> and they're arch dependent, irrespective of how the ocaml 
> executables are built.

Sure, then you are in the advi example, not the spamoracle one, and -custom is
indeed preferable. I think the policy mentions something of this kind.

Now, the idea thing is to move the c++ bindings in their own binary package,
and you fall again in the spamoracle example.


Sven Luther

Reply to: