Re: packages which can be arch: all and arch: any ...
On Fri, Oct 04, 2002 at 11:25:55AM -0400, Joey Hess wrote:
> 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
Well, what about the coq for example, which is 7 MB package (on i386, so
maybe it is bigger for other arches) and 20MB installed.
There may be other packages as well.
For package who don't really need to be that quick, we build only the
bytecode anyway (ledit or hevea for example).
There is also the buildd resources, especially on the slower
arches. I guess it takes much time to build coq on m68k for example,
while i could have built the exact same executable on my i386 box.
> 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.
But if we can package them in a transparent way for the user, and
without much effort on the developpers side, it is worth the effort, is
it not ?
> 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.
Mmm, do you have a pointer to were i can look more at this ideas.
Friendly,
Sven Luther
Reply to: