Re: proposal: native/bytecode executables proposal
On Sat, Oct 19, 2002 at 11:11:32AM +0200, Stefano Zacchiroli wrote:
> On Sat, Oct 19, 2002 at 10:25:30AM +0200, Stefano Zacchiroli wrote:
> > o the native version of this package will be called foo, and built on
> > arches supporting the native code compiler. Ocaml will provide a file
> > listing all native code supporting arches, so you can easily use it
> > for your packages. I am afraid you will have to copy this file over
> > each time, since it can not be done automatically, i think, but then
> > maybe with a clever substitution rule, it can be obtained.
>
> 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.
> > o the bytecode version of this package will be called foo-byte or
> > foo-vm, or some other prefix we feel is more appropriated. It will be
> > built arch: all and provide foo. When apt-get install foo is run, it
> > will choose the real foo over the virtual foo on arches supporting
> > the native code, and will choose the virtual foo on arches where only
> > the bytecode version is present. I will test this this WE, and inform
> > you, but this is what i was told when i asked the apt maintainers
> > about it.
>
> If this work as you said, it will be perfect. Anyway IMO is a good idea
> to ask the apt maintainers if this behaviour is granted or if it is a
They were not clear about this, i will first check if it works, and then
ask them, maybe try to make it policy even.
> side effect. In any case we should better ask for some kind of
> certainity that this behaviour will not change in the future, this is
> a crucial issue for the ocaml packages.
Yes, ...
BTW, one response i got was that, unless the packages are >20MB, then it
is not worth it. I told him about coq then, and he said it was big
enough to be considered.
> > The only bad side of this is that we will create additional dependencies
>
> I see another bad side: the damned version dependencies problem for
> virtual packages.
Mmm, yes, ...
> 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.
Also we could use the ocaml-3.06 trick to do versioned dependencies as
needed.
Another solution would be to fix the versioned virtual dependency
problem in dpkg.
Friendly,
Sven Luther
Reply to: