On Thu, Nov 05, 2009 at 09:49:07AM +0100, Thilo Bangert wrote:
>
> > Perhaps the pragmatic approach might be wise.
> >
>
> when filing the FEATURES bugs, i (IIRC) tried to remain on the pragmatic
> side, recognising the sometimes non-existing alternatives. ie. i didnt
> open bugs for each and every FEATURES usage.
>
> the tracker bug is here:
> http://bugs.gentoo.org/show_bug.cgi?id=174335
While I appreciate you being pragmatic in your cleanup efforts, you
miss the point of my post- while FEATURES reliance needed a valid
reason from a QA standpoint, it was *valid* from a format standpoint
prior to paludis/PMS (and was the only option in some corner cases
ebuild wise).
The response these days when it comes to FEATURES is that you cannot
rely on it's existance ever- this loops back to my point about
pragmatism.
I understand PMS/paludis wishing to duck the vars existance to make it
go away, but I don't think it's a tenuable approach- as you yourself
said above, in trying to do this cleanup you recognized that sometimes
there was no alternative.
Please understand my point here is QA; not picking a fight. That
said, paludis doesn't do anything FEATURES wise due to PMS not
mandating they do so... as you said, certain ebuilds rely on it's
existance to work.
This means via PMS being incomplete, paludis isn't going to play nice
in those cases (corner case- if the user defines the var themselves in
their config, this would address it).
Essentially, you can't use FEATURES but you have to in some cases.
Doing so however doesn't necessarily play nice w/ paludis due to
stepping outside of PMS. Classic catch 22.
Rather then letting the problem persist, I'd rather see folk take a
look at FEATURES/PMS and identify what needs to be pushed in to take
care of the cases where there is no alternative to 'hasq some-feature
$FEATURES' rather then us just collectively sticking our heads in the
sand.
Grok?
Or we can just keep ignoring the problem pretending it's a user config
issue rather then a format level issue...
~harring
|
