Re: packages which can be arch: all and arch: any ...
On Fri, Oct 04, 2002 at 09:12:52AM +0200, Matthias Urlichs wrote:
> Hi,
>
> Sven LUTHER:
> > Is there a way to handle this so that apt will get the native code
> > package if it is available, and resort to the bytecode one on arches not
> > supporting the native code compiler ? Some sort of priorities or
> > something such ?
> >
> I'd split the packages in three:
> - ocaml (arch-independent, common stuff)
> - ocaml-bytecode (ditto, bytecode interpreter)
> - ocaml-native (arch-dependent, compiles to native code)
Well, it is not so much about the ocaml package, which is already
suitably splitted (the bytecode interpreter is in ocaml-base), but about
packages built with ocaml.
> The latter two provide a common symbol "ocaml-runtime", both require ocaml;
> ocaml requires "ocaml-runtime"; either -native can conflict with -bytecode
> and vice versa, or you select which you want via the alternatives
> mechanism.
>
> For archs which don't have a native compiler, there's simply no choice.
Ok, but then the user will have to specify which version they want
installed, and this is what i wanted to solve. That is, i want for the
user not to have to worry about the native/bytecode packages, and have
the best available installed when he does apt-get install foo.
> > BTW, is there a more appropriated list for this kind of question ?
> >
> Not that I know of.
>
> > BTW2, if i go with virtual packages, i will most probably run with
> > problems on versioned dependencies
>
> You don't need them here. -bytecode and -native can even be versioned
> independently; if a program has a problem with an old -native it can
> register a conflict with lower versions of it.
Mmm, <thinking about it ...>, mmm, yes i see what you mean. Since the
bytecode packages are dependant only on other bytecode packages they can
provide a real dependency, the same goes for the native packages.
But then the problem is with a package, say bar, which knows nothing
about ocaml, and has a versioned dependency on foo, and does not want to
have to worry about wheter it is a bytecode or a nativecode version that
fullfills this dependency, then it cause problem.
Not so easy a solution for this finally, and, altough maybe not right
now, we may one day need versioned dependencies for this.
(Well, we can always fake them with a virtual package foo-1.2.3 or
something such, but it is not the cleanest solution).
Anyway, thanks for your response.
Friendly,
Sven Luther
>
> --
> Matthias Urlichs | noris network AG | http://smurf.noris.de/
Reply to: