Ciaran McCreesh napsal(a):
> 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.

Erm, what are you talking about here? What is there to be kept in sync
with profiles?

> | > Yup. Default USE flags are profile dependent data. The sensible
> | > default value varies depending upon conditions like arch and system
> | > role.
> | 
> | You are really circular, fix your record player :P
> 
> That's not even remotely circular. They're profile dependent, so they
> belong in the profile. There is no circular.

You didn't say yet _WHY_ they are profile dependent. Repeating your
statement ad nauseam won't fix your record player really.

> | Defaults that makes sense in profiles can and will stay there and
> | noone's damn forcing you to change it. We are talking about
> | per-package (or per-ebuild even) stuff here, which is a feature that
> | has been missing for ages.
> 
> Which is solved quite happily in the profiles by package.use, and
> without the problems associated with the IUSE solution.

Which problems? And how is duplicating the info across various profiles
easier than sticking the darned +foo into IUSE and having it sticky
regardless of to whichever overlay/repo I copy the ebuild?

> You know Jakub, you'd be a lot less stressed if you sat down and
> thought about what was being discussed before posting.

Looks to me like you are actually the only one missing the whole point
of this feature. I guess I'd be a lot less stressed if you brought some
arguments to the discussion instead of repeating yourself over and over
again without backing up your claims in any way.



-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to