28.2.2006, 15:39:40, Ciaran McCreesh wrote: > On Tue, 28 Feb 2006 10:49:13 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote: > | No, that's not a policy document, ebuild policy is documented here: > | > http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=printable&part=3&chap=1
> No, the whole thing is policy. No, it isn't. And silently sticking parts of unofficial gentoo devmanual into official Gentoo docs, and then silently turning them into a "policy" enforced under QA disguise is a bad very practice, and pretending that this has been in the mentioned _howto_ (not policy) for a long time as just plain silly. Since you haven't answered the question in one of my previous emails at all, let me ask again: When and where has been the following change discussed and who approved that? http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?r1=1.25&r2=1.26&root=gentoo > | Moreover, the cited howto is wrong, since it will break built_with_use > | checks > No, that's a separate issue. No, it isn't. If you want something to have as a policy, it needs to be error-free, reasonably applicable and not doing more harm than if it isn't applied at all. And implementing such stuff requires a proper discussion, considering the consequences and some sort of consent among affected developers. (Also, that howto example is less than fortunate/clear, like some user noted in Bug 124401). > | The howto also doesn't apply to cases like > | recode vs. mysql, because that's a completely different > | functionality, you can't exactly choose which one is better on behalf > | of the user. > No, it does apply. No, it doesn't, you can't reasonably favour one of two completely different functionalities based on some automagic assumption/developer discretion. That doesn't benefit users in any way and just produces unexpected results (hey, I explicitely enabled "recode" use flag and php compiled without, the ebuild is broken, fix0r it!) > | So, to sum it up - you can't make up for portage's lack of features by > | inventing a policy that doesn't work. Once again - until portage can > | handle USE-based dependencies and until portage can handle > | conflicting use flags, there's nothing that could be done here. > Until Portage can handle conflicting USE flags, one should take the > policy-mandated solution that has been sufficient for everyone else for > four years or more. Sure, it's not perfect, but it's a hell of a lot > better than repeatedly exploding in the user's face midway through an > install. No, noone should enforce a policy that - doesn't exist (see above) - hasn't been discussed properly and approved (see above) - it's consequences haven't been considered wrt whether its benefits overweight the negatives and whether is useful at all. -- 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 ;)
pgpj5iahK5mPv.pgp
Description: PGP signature
