| 1 |
[snip] |
| 2 |
|
| 3 |
> I understand PMS/paludis wishing to duck the vars existance to make it |
| 4 |
> go away, but I don't think it's a tenuable approach- as you yourself |
| 5 |
> said above, in trying to do this cleanup you recognized that sometimes |
| 6 |
> there was no alternative. |
| 7 |
|
| 8 |
yes - however, there not being an alternative at the moment does not |
| 9 |
automatically mean that FEATURES is a good or the best approach. A more |
| 10 |
clean approach still needs to be proposed. |
| 11 |
|
| 12 |
[snip] |
| 13 |
|
| 14 |
> |
| 15 |
> Rather then letting the problem persist, I'd rather see folk take a |
| 16 |
> look at FEATURES/PMS and identify what needs to be pushed in to take |
| 17 |
> care of the cases where there is no alternative to 'hasq some-feature |
| 18 |
> $FEATURES' rather then us just collectively sticking our heads in the |
| 19 |
> sand. |
| 20 |
|
| 21 |
yes - exactly. so which FEATURES are absolutely required in ebuilds / |
| 22 |
eclasses for which an alternative must be developed? |
| 23 |
|
| 24 |
> |
| 25 |
thanks for your input, BTW |
Archives