On Fri, 13 Oct 2006 02:40:59 -0700 Zac Medico <[EMAIL PROTECTED]> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi everyone, > > I've written a patch for portage [1] that implements per-package > default USE flags at both the ebuild and profile levels (discussed a > couple of months ago [2] on this list). At the ebuild level, default > flags are specified in IUSE with a + prefix as described in bug > #61732 [3]. At the profile level, I've added support for package.use > which behaves like /etc/portage/package.use that everyone is familiar > with. The intention is that the IUSE defaults will be used for > default flags that should be enabled regardless of profile. Then, > package.use will be used for flags that might vary depending on the > profile. For example, a server profile might enable server flags and > a desktop profile might enable client flags. > > Aside from being package specific, the per-package default USE flags > behave much like USE flags that are currently listed in profiles' > make.defaults. The flags are stacked incrementally as usual. The > ebuild level defaults are at the bottom of the stack, followed by > make.defaults, and finally package.use. The user can override these > new flags in the same was as make.defaults USE flags could always be > overridden (make.conf and package.use). > > Should we include support in portage for one or both types of > per-package default USE flags? If support is included for IUSE > defaults now, we won't be able to use them in the tree until after a > waiting period or an EAPI bump [4]. I think adding both is fine, assuming that profile package.use overrides the IUSE defaults. Though not sure if "pkginternal" should come before or after the "defaults" in USE_ORDER, both make some sense to me (but that's a detail that's trivial to change, so don't get distracted by it too much). Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. -- [email protected] mailing list
