OEDEM 2009 summary: DISTROs and FEATURES

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.

Re: OEDEM 2009 summary: DISTROs and FEATURES

[Przemyslaw Wesolek]

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

In consequence, this also holds for DEPLOY_DIR_PSTAGE making TMPDIR and
DISTRO immutable.

Przemek

Re: OEDEM 2009 summary: DISTROs and FEATURES

[Phil Blundell]

On Wed, 2009-11-11 at 19:30 +0100, Przemyslaw Wesolek wrote:
> Phil Blundell wrote:
> > d) for a given TMPDIR, the DISTRO setting is immutable.  If you change
> > DISTRO you must rebuild from scratch in a different working tree.
> 
> In consequence, this also holds for DEPLOY_DIR_PSTAGE making TMPDIR and
> DISTRO immutable.

I think the standard configuration is for DEPLOY_DIR_PSTAGE to be within
TMPDIR, so the two things tend to go together.  But you're right, a
DISTRO change would indeed invalidate the contents of DEPLOY_DIR_PSTAGE.

p.

Re: OEDEM 2009 summary: DISTROs and FEATURES

[Detlef Vollmann]

On 11/11/09 17:36, Phil Blundell wrote:
> 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.
This ('build environment') could be misleading.
I'd say it this way:
  DISTRO defines what to build
  local.conf defines, how to build (directory paths, parallelism, ...)

   Detlef