1 |
28.2.2006, 16:29:10, Ciaran McCreesh wrote: |
2 |
|
3 |
> On Tue, 28 Feb 2006 16:08:05 +0100 Jakub Moc <jakub@g.o> wrote: |
4 |
> | 28.2.2006, 15:39:40, Ciaran McCreesh wrote: |
5 |
| >> On Tue, 28 Feb 2006 10:49:13 +0100 Jakub Moc <jakub@g.o> |
6 |
| >> wrote: |
7 |
| >> | No, that's not a policy document, ebuild policy is documented |
8 |
| >> | here: |
9 |
| >> | |
10 |
| >> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=printable&part=3&chap=1 |
11 |
> | |
12 |
| >> No, the whole thing is policy. |
13 |
> | |
14 |
> | No, it isn't. |
15 |
|
16 |
> 'Fraid it is. Everything in the devrel handbook that isn't explicitly |
17 |
> marked as a guideline is policy. |
18 |
|
19 |
Sorry, such procedure is not acceptable until you change the whole |
20 |
metastructure of the project so that a bunch of people is allowed to dictate |
21 |
to others whatever they think is fit. (Another question is how many people |
22 |
will want to work on such project.) Until that's done, things should be |
23 |
discussed and some form of consent reached. |
24 |
|
25 |
> | When and where has been the following change discussed and who | |
26 |
> approved that? | | |
27 |
> 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 |
28 |
|
29 |
> Wouldn't know. That was nothing to do with me. I just wrote the |
30 |
> original text (or actually, that might not even have been me). It |
31 |
> finding its way into the policy docs was devrel's doing. |
32 |
|
33 |
Again, see above. |
34 |
|
35 |
| >> | Moreover, the cited howto is wrong, since it will break |
36 |
| >> | built_with_use checks |
37 |
> | |
38 |
| >> No, that's a separate issue. |
39 |
> | |
40 |
> | No, it isn't. If you want something to have as a policy, it needs to |
41 |
> | be error-free, reasonably applicable and not doing more harm than if |
42 |
> | it isn't applied at all. And implementing such stuff requires a |
43 |
> | proper discussion, considering the consequences and some sort of |
44 |
> | consent among affected developers. (Also, that howto example is less |
45 |
> | than fortunate/clear, like some user noted in Bug 124401). |
46 |
|
47 |
> built_with_use isn't a question of conflicting USE flags. It's a |
48 |
> separate question of dependency resolution, and in this situation it |
49 |
> *can't* be solved using the method that's been standard for four years |
50 |
> or more. |
51 |
|
52 |
Sure it is. You can't silently enable/disable some feature if other ebuilds |
53 |
are checking for that feature using those very use flags that you have |
54 |
ignored/overriden/bypassed. Such checks are useless then and more stuff gets |
55 |
broken than gets fixed. |
56 |
|
57 |
> | No, it doesn't, you can't reasonably favour one of two completely | |
58 |
> different functionalities based on some automagic | assumption/developer |
59 |
> discretion. That doesn't benefit users in any | way and just produces |
60 |
> unexpected results (hey, I explicitely enabled | "recode" use flag and php |
61 |
> compiled without, the ebuild is broken, | fix0r it!) |
62 |
|
63 |
> By all means warn the user. There's nothing in policy disallowing that. |
64 |
|
65 |
That doesn't work, it breaks other things as explained above. Please, don't |
66 |
use a hammer where watchmaker's screwdriver is a proper tool, otherwise |
67 |
you'll severely damage the whole thing. One minute spent on tweaking use |
68 |
flags is much less important than a bunch of useful features missing just |
69 |
because you've hammered the whole stuff together. |
70 |
|
71 |
> | No, noone should enforce a policy that |
72 |
> | |
73 |
> | - doesn't exist (see above) |
74 |
|
75 |
> The whole devrel handbook is policy, except where otherwise noted. See |
76 |
> Mike's reply. |
77 |
|
78 |
Then any significant change there requires a sane procedure. |
79 |
|
80 |
|
81 |
-- |
82 |
|
83 |
jakub |