Sven LUTHER wrote: > 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. Well if I were you I would avoid the route of splitting off a bunch of -bytecode and -native packages and simply make it arch any and build natice packages on arches where I could, and bytecode packages elsewhere. It uses up a bit of archive space, but is no worse than any compiled program. Trying to save a snidgeon of archive space just because you can here is a kind of false optimization, as you are introducing a lot of unnecessary complexity, both for yourself and for the user in the process of doing so. If these packages are 20 or 100 mb in size, it might be worth trying to optimize for space, but if they are fairly normal in size, it's probably more important to package them in a comprehensible and simple manner. If you really wanted to solve this one right, you could think about implementing Marcus Brinkman's idea that lets packages depend on their architecture(s). That's nice because it solves the general problem you are running into: That of arch "all" packages that are really only useful on a subset of architectures. -- see shy jo
Attachment:
pgpl9artZYF2j.pgp
Description: PGP signature