1 |
On Tue, 3 Nov 2009 21:36:18 +0100 |
2 |
Patrick Lauer <patrick@g.o> wrote: |
3 |
> Userpriv I've seen the funny idea to check if UID=0 and such. |
4 |
|
5 |
Yes, and that 'funny idea' has the added advantage of working even if |
6 |
userpriv is in FEATURES but not actually enabled (yes, that can happen). |
7 |
|
8 |
> > > To quote: |
9 |
> > > "FEATURES is a portage specific package manager configuration |
10 |
> > > variable not specified in PMS and cannot reliably be used in |
11 |
> > > ebuilds or eclasses." |
12 |
> > |
13 |
> > Makes sense to me atm. |
14 |
> |
15 |
> Makes no sense to me, but then I seem to be special :) |
16 |
|
17 |
PMS doesn't document user configuration. If PMS did document user |
18 |
configuration, it would mean that user configuration file formats |
19 |
couldn't arbitrarily be changed between package manager versions as |
20 |
they are now. |
21 |
|
22 |
If FEATURES were specified by PMS, Portage wouldn't be able to change |
23 |
the meaning of its entries without careful EAPI controls. So far as I'm |
24 |
aware, no-one is in favour of introducing such a restriction. There |
25 |
are easy alternatives available, and unlike checking FEATURES, those |
26 |
alternatives actually work. |
27 |
|
28 |
> And all my attempts to get it fixed have been deflected, so I'll keep |
29 |
> ridiculing it until it stops being a failwhale. |
30 |
|
31 |
Patrick, perhaps you would find your efforts more fruitful were you to |
32 |
respond to reviews of your patches by fixing the issues raised, instead |
33 |
of using every available opportunity you can find to take pot-shots at |
34 |
PMS, close off legitimate bugs as INVALID and generally attempt to make |
35 |
life as hard as possible for those for whom PMS matters most. |
36 |
|
37 |
Of the small number of patches that have ended up being rejected from |
38 |
PMS, all but one have been yours, and the one that wasn't was because |
39 |
the author had mistranslated a phrase. I'd appreciate it if you would |
40 |
stop to consider why this is the case. |
41 |
|
42 |
-- |
43 |
Ciaran McCreesh |