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. _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
