Re: proposal: native/bytecode executables proposal
On Mon, Oct 21, 2002 at 09:20:46AM +0200, Stefano Zacchiroli wrote:
> On Sat, Oct 19, 2002 at 01:16:12PM +0200, Sven Luther wrote:
> > > We can write some substitution tools for debhelpers that will expand a
> > > variable like ${ocaml-native-archs} to the list of the current archs
> > > supported by the ocaml native code compiler.
> > Well, i am not sure this will work, since the substitution may come
> > before the packaging stuff, in particular it has to be used only by the
> > packager, and once the package is uploaded, the autobuilders need to
> > know the arch list before they build, so this limits us some.
>
> I've never thought about it, have you tried anyway?
Yes, i wanted to make the ocaml-3.06 and ocaml-base-3.06 automatically
generate the 3.06 part from a variable of debian/rules.
It worked fine for the .changes, but the .dsc, which is generated at the
begining of the build, did not yet have the substituted variables, and
the autobuilders will complain strongly to that.
> > > On archs which don't support native code compiler, foo-bytecode will
> > > provide foo, right? So on these archs how does the packaging system
> > > react if another package depends on foo >= x.y.z?
> >
> > Then you do a dependency on :
> >
> > foo | foo-native ? with the versioned dependency, that is.
>
> You probably meant "foo | foo-bytecode (>= x.y.z)", in your schema there
> was no "foo-native" package.
Yes, but i guess it will have to have foo (>= x.y.z) | foo-byte (>=
x.y.z)
> Anyway I don't know if it can work, let's see:
> a) foo is available as a real package, ok
only if it does have the dependency on foo also.
> b) foo i provided by foo-bytecode so we have foo-bytecode (real package)
> and foo (provided by foo-bytecode), the versioned dep can work, but
> is a bit tricky, this need to be checked.
Why, it will work normally. the foo-byte (>= x.y.z) dependency can only
be satisfied in one way, by installing foo-byte.
> Is probably better "foo-bytecode (>= x.y.z) | foo" but the behaviour
> with which apt choose the package is not granted so this is probably
> a bad idea.
It will work, all right, but it means more crufft in the dependencies.
> > Also we could use the ocaml-3.06 trick to do versioned dependencies as
> > needed.
>
> brrr ... on all packages that need versioned dep? this is really
> overkillinkg!
It is a nice workaround, think about it like the ..so versions, you
change it only in case of incompatibility.
This would even void all the need for >, >=, <, <= in the dependencies.
It is a rather clean solution, altough the provides field may not really
be the right place for this. Maybe even cleaner than using the versioned
dependencies, like we did see when i introduced ocaml-3.06 as a virtual
package. It needs some planing and some work though.
Also notice, i could have ocaml-cvs provide ocaml-3.06 as long as the
.cm* format is not changed. Once it is changed, i will have to change
the virtual package to ocaml-3.06+cvs-date or something such.
> > Another solution would be to fix the versioned virtual dependency
> > problem in dpkg.
>
> I suspect this is the only possible solution :-(
> (other than don't using versioned dependencies :)
Yes, a lot of work though, but then, our saving is that it is C code,
not some strange stuff.
Friendly,
Sven Luther
Reply to: