[oe] OEDEM 2009 summary: DISTROs and FEATURES

[Phil Blundell]

One topic which crops up on the mailing list now and again is the
tension between, on one hand, the desire to have packages tailored to
particular requirements or applications (for example, no x11 libs on a
system that never runs X); and, on the other hand, the desire for
"reproducible" builds.  How can we resolve this?

After a bit of discussion we arrived at the following principles.  I
think most/all of these are really just a formalisation of existing
practice rather than a radically new departure, but I don't think they
have previously been spelled out in this form:

a) a DISTRO represents a coherent set of binaries that are expected to
work together for a given MACHINE.  (If the distro chooses, there may
also be scope to share binary packages between sets of MACHINEs.)

b) we accept that, if the end user chooses to override parts of the
DISTRO configuration, there are nonetheless a myriad ways in which he
can generate incompatible binaries.  There doesn't seem to be much to
say about this other than to discourage users from doing it.

c) there is no expectation that binaries from different DISTROs, even on
the same MACHINE, should be compatible.  (For example, they might use
different C libraries or even different endianness.)

d) for a given TMPDIR, the DISTRO setting is immutable.  If you change
DISTRO you must rebuild from scratch in a different working tree.

e) DISTROs should be encouraged to minimize the number of unbound
variables which the user is expected to set in local.conf.  As a general
principle, the tuple of (MACHINE, DISTRO) should be enough to completely
determine the build environment.  Extra user-frobbable switches will
undermine the coherence of the DISTRO.

f) DISTROs have wide discretion to determine the contents of their own
binary packages (e.g. configuring python with or without x11 support)
and we should provide them with the mechanisms to do so.  There are
already various ad-hoc mechanisms to accomplish this for certain
packages (e.g. USE_LDCONFIG in glibc) and it would be desirable to come
up with a more over-arching framework.

g) the existing DISTRO_FEATURES variable is well suited to this role.
We should encourage DISTROs to use it where conditionality is needed
rather than inventing alternatives.

p.