packages which can be arch: all and arch: any ...

[Sven LUTHER <luther@dpt-info.u-strasbg.fr>]

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