28.2.2006, 16:29:10, Ciaran McCreesh wrote: > On Tue, 28 Feb 2006 16:08:05 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote: > | 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.
> 'Fraid it is. Everything in the devrel handbook that isn't explicitly > marked as a guideline is policy. Sorry, such procedure is not acceptable until you change the whole metastructure of the project so that a bunch of people is allowed to dictate to others whatever they think is fit. (Another question is how many people will want to work on such project.) Until that's done, things should be discussed and some form of consent reached. > | 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 > Wouldn't know. That was nothing to do with me. I just wrote the > original text (or actually, that might not even have been me). It > finding its way into the policy docs was devrel's doing. Again, see above. | >> | 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). > built_with_use isn't a question of conflicting USE flags. It's a > separate question of dependency resolution, and in this situation it > *can't* be solved using the method that's been standard for four years > or more. Sure it is. You can't silently enable/disable some feature if other ebuilds are checking for that feature using those very use flags that you have ignored/overriden/bypassed. Such checks are useless then and more stuff gets broken than gets fixed. > | 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!) > By all means warn the user. There's nothing in policy disallowing that. That doesn't work, it breaks other things as explained above. Please, don't use a hammer where watchmaker's screwdriver is a proper tool, otherwise you'll severely damage the whole thing. One minute spent on tweaking use flags is much less important than a bunch of useful features missing just because you've hammered the whole stuff together. > | No, noone should enforce a policy that > | > | - doesn't exist (see above) > The whole devrel handbook is policy, except where otherwise noted. See > Mike's reply. Then any significant change there requires a sane procedure. -- jakub
pgp3XISjAzxvT.pgp
Description: PGP signature
