Re: USE flags ??
On Tue, Oct 26, 2004 at 12:02:19PM +0100, Jon Dowland wrote:
} On Thu, 21 Oct 2004 12:48:53 +0100, David Dorward <dorward@gmail.com> wrote:
}
} > USE flags specify (mostly) what optional packages
} > to compile against. For Debian to do this, all packages would have to
} > be compiled against all combinations of all optional dependancies. As
} > it is, without that level of choice, Debian is already too big to fit
} > on a DVD! (And that doens't begin to cover the additional level of
} > testing that would be required).
}
} I've been meaning to get some stats for some time - but I'd be
} interested to see how feasible it would be to package up the binary .o
} files for a package and the linking stage would be done locally -
} advantages: faster than compiling all from scratch for user. Assuming
} that a program built with configuration X and configuration Y share a
} significant subset of .o files; the package could include the superset
} (so, you download the .o files, and link according to your preferences
} e.g. X support). Dynamic dependencies so if you don't want emacs with
} x support, you don't pull in the x libraries, but the mirror still
} only has one X package (albeit with spare .o's for the two
} configurations). Disadvantages: the linking stage means slower than a
} straight binary download. Slightly larger packages (well, that all
} depends on how many .o files the configuration change would impact)
}
} An alternative would be a subset of common .o's and a small compile
} job for the user. I guess gentoo could reach this stage just by having
} a distribution-wide distributed ccache, or something.
We call collections of .o files "libraries," sometimes distributed as
"static libraries" but more often as "dynamic libraries." Many of the
packages in Debian are divided into these so-called "libraries" and
executables which depend on them. If you can justify the work to separate
out the bits of these "libraries" that depend on things you don't (or might
not) want, and turn them into their own separate packages, feel free to
dedicate the time to it. Someone might even care, and the package
organization might change such that it is possible to install only the
functionality you want.
Be warned, however, that this is a non-trivial task. This is not how most
software packages are designed and one can expect it to be a lot of work
for very little benefit. In fact, one might argue that it is exactly
because of this cost/benefit ratio that no one has bothered to do it for
the vast majority of packages. It is free software, however, and you are
welcome to muck with it as you see fit and you are encouraged to release
and promote your contributions.
(Note: Yes, quoting libraries was deliberate sarcasm.)
} Jon Dowland
--Greg
Reply to: