| 1 |
28.2.2006, 15:39:40, Ciaran McCreesh wrote: |
| 2 |
|
| 3 |
> On Tue, 28 Feb 2006 10:49:13 +0100 Jakub Moc <jakub@g.o> wrote: |
| 4 |
> | No, that's not a policy document, ebuild policy is documented here: |
| 5 |
> | |
| 6 |
> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=printable&part=3&chap=1 |
| 7 |
|
| 8 |
> No, the whole thing is policy. |
| 9 |
|
| 10 |
No, it isn't. And silently sticking parts of unofficial gentoo devmanual |
| 11 |
into official Gentoo docs, and then silently turning them into a "policy" |
| 12 |
enforced under QA disguise is a bad very practice, and pretending that this |
| 13 |
has been in the mentioned _howto_ (not policy) for a long time as just plain |
| 14 |
silly. Since you haven't answered the question in one of my previous emails |
| 15 |
at all, let me ask again: |
| 16 |
|
| 17 |
When and where has been the following change discussed and who approved |
| 18 |
that? |
| 19 |
|
| 20 |
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 |
| 21 |
|
| 22 |
|
| 23 |
> | Moreover, the cited howto is wrong, since it will break built_with_use |
| 24 |
> | checks |
| 25 |
|
| 26 |
> No, that's a separate issue. |
| 27 |
|
| 28 |
No, it isn't. If you want something to have as a policy, it needs to be |
| 29 |
error-free, reasonably applicable and not doing more harm than if it isn't |
| 30 |
applied at all. And implementing such stuff requires a proper discussion, |
| 31 |
considering the consequences and some sort of consent among affected |
| 32 |
developers. (Also, that howto example is less than fortunate/clear, |
| 33 |
like some user noted in Bug 124401). |
| 34 |
|
| 35 |
> | The howto also doesn't apply to cases like |
| 36 |
> | recode vs. mysql, because that's a completely different |
| 37 |
> | functionality, you can't exactly choose which one is better on behalf |
| 38 |
> | of the user. |
| 39 |
|
| 40 |
> No, it does apply. |
| 41 |
|
| 42 |
No, it doesn't, you can't reasonably favour one of two completely different |
| 43 |
functionalities based on some automagic assumption/developer discretion. |
| 44 |
That doesn't benefit users in any way and just produces unexpected results |
| 45 |
(hey, I explicitely enabled "recode" use flag and php compiled without, the |
| 46 |
ebuild is broken, fix0r it!) |
| 47 |
|
| 48 |
> | So, to sum it up - you can't make up for portage's lack of features by |
| 49 |
> | inventing a policy that doesn't work. Once again - until portage can |
| 50 |
> | handle USE-based dependencies and until portage can handle |
| 51 |
> | conflicting use flags, there's nothing that could be done here. |
| 52 |
|
| 53 |
> Until Portage can handle conflicting USE flags, one should take the |
| 54 |
> policy-mandated solution that has been sufficient for everyone else for |
| 55 |
> four years or more. Sure, it's not perfect, but it's a hell of a lot |
| 56 |
> better than repeatedly exploding in the user's face midway through an |
| 57 |
> install. |
| 58 |
|
| 59 |
No, noone should enforce a policy that |
| 60 |
|
| 61 |
- doesn't exist (see above) |
| 62 |
- hasn't been discussed properly and approved (see above) |
| 63 |
- it's consequences haven't been considered wrt whether its benefits |
| 64 |
overweight the negatives and whether is useful at all. |
| 65 |
|
| 66 |
|
| 67 |
-- |
| 68 |
Best regards, |
| 69 |
|
| 70 |
Jakub Moc |
| 71 |
mailto:jakub@g.o |
| 72 |
GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E |
| 73 |
Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E |
| 74 |
|
| 75 |
... still no signature ;) |
Archives