On Sun, 2006-10-15 at 22:01 +0100, Ciaran McCreesh wrote: > On Sun, 15 Oct 2006 22:35:10 +0200 Jakub Moc <[EMAIL PROTECTED]> wrote: > | > Which is why I suggested changing Portage's behaviour earlier in the > | > thread. Like it or not, overlays are already getting complex enough > | > that they'd benefit from profile behaviour. > | > | Because maintaining your own profiles and stacking them and dealing > | with all the related mess is a _lot_ easier that sticking a + before > | foo in IUSE. Right. ;) > > You mean, than sticking a + before foo in IUSE in every ebuild, and > ensuring that changes are kept in sync and consistent with the > behaviour of every single existing profile.
No one here is talking about doing that... What we are talking about is an instance where foo is *not* enabled by default in profiles but there is *one* package where it is upstreams intention that foo be enabled by default but they still provide the capability to turn foo support off. This package (and all of the ebuilds that are in the tree for it) would have a +foo in IUSE...thus even though foo is generally off unless the user specifies -foo in either make.conf or package.use foo is turned on for this package and this package alone. No one is talking about replacing tree wide defaults with this functionality...this is for package maintainers to specify default behavior for their package and their package alone independent of the profiles intent. Doing it your way in order to make sure that a package was built the way a maintainer intended (by default) they would have to make an entry in package.use in every single tier one profile (at the moment only base)...this is also something that they cannot enforce over external overlays...so it looses any value at all. --Dan
signature.asc
Description: This is a digitally signed message part
