Hello, ... Well, this will be a complex question, and the subject is not all that speaking, i apologize for it...
I maintain the ocaml package, which is a language which can produce bytecode executables to be run in a virtual machine (as java does) or native code executables (well, the source is converted to asm and then assembled by gcc) on a limited range of arches (alpha, arm, i386, ia64, powerpc and sparc). Since the bytecode executables are arch independent, i think it would be nice to build them arch: all, since this would mean, apart from smaller sized packages, also that we don't have 12+ version of the same thing in the archive (well, at least we can spare all the arches which do not support native code compilers). But then, on arches supporting the native code compiler, we want to build the app as native code, since this will result in faster executables. That said, my first idea was, for a source package foo, to have a binary package foo containing the bytecode executable and being arch: all, and a binary package foo-native for the 6 arches who support it (which would replace, provide and all that is needed the foo package). The problem is that for the native supporting arches, both the arch: all and the native code package is available, one being called foo, the other providing foo. It is my guess that if a user does an apt-get install foo, he will get the bytecode package, even if the native code is available. 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 ? BTW, is there a more appropriated list for this kind of question ? BTW2, if i go with virtual packages, i will most probably run with problems on versioned dependencies, do someone know what is the problem with that, if there is a fundamental flaw with doing them, or if it is only the manpower to implement them which is at fault. Friendly, Sven Luther
