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/
