Re: [gentoo-dev] FEATURES use or misuse?

[Patrick Lauer]

On Tuesday 03 November 2009 21:58:27 Ciaran McCreesh wrote:
> On Tue, 3 Nov 2009 21:36:18 +0100
>
> Patrick Lauer <patrick@g.o> wrote:
> > Userpriv I've seen the funny idea to check if UID=0 and such.
>
> Yes, and that 'funny idea' has the added advantage of working even if
> userpriv is in FEATURES but not actually enabled (yes, that can happen).
>
I would consider that a bug. Maybe fixing that bug is easier than 
workarounding it?

> > > > To quote:
> > > > "FEATURES is a portage specific package manager configuration
> > > > variable not specified in PMS and cannot reliably be used in
> > > > ebuilds or eclasses."
> > >
> > > Makes sense to me atm.
> >
> > Makes no sense to me, but then I seem to be special :)
>
> PMS doesn't document user configuration. If PMS did document user
> configuration, it would mean that user configuration file formats
> couldn't arbitrarily be changed between package manager versions as
> they are now.
I fail to see which part of "It's a key-value list, like the old windows .ini 
files, with comments starting with # allowed" is so specially specific that it 
can't be documented. But then I often fail to notice such obvious 
obviousities.

> If FEATURES were specified by PMS, Portage wouldn't be able to change
> the meaning of its entries without careful EAPI controls. So far as I'm
> aware, no-one is in favour of introducing such a restriction. There
> are easy alternatives available, and unlike checking FEATURES, those
> alternatives actually work.
That is concentrated nonsense. You're implying that an ebuild setting (EAPI) 
can control the package manager configuration. That's so exquisitely backwards 
and incoherent that I'm having a hard time taking you serious.

If PMS defined the existance of a FEATURES variable (like, say, CFLAGS) then 
the contents of that variable could be arbitrary whitespace-separated strings.

Amazingly CFLAGS is not EAPI-controlled and can take arbitrary values, so 
generalizing that amazing functionality to other configuration variables 
should be an easy exercise for the advanced reader.

Once that is done it can be specialized to a FEATURES variable, which is 
exactly what we expected.

>
> > And all my attempts to get it fixed have been deflected, so I'll keep
> > ridiculing it until it stops being a failwhale.
>
> Patrick, perhaps you would find your efforts more fruitful were you to
> respond to reviews of your patches by fixing the issues raised,
I'm trying to do that. And you might want to not patronize me (especially in 
an academic setting that would be terribly rude, on the internet it's just 
silly)

The fact that there are a few dozen violations of PMS that are bastardly 
expensive to rollback suggests that harmonizing PMS to reality may be the 
cheaper method. Trying to bend reality to fit the specification can be an 
amusing game, but has a very high chance of failing hard.

> instead
> of using every available opportunity you can find to take pot-shots at
> PMS, close off legitimate bugs as INVALID and generally attempt to make
> life as hard as possible for those for whom PMS matters most.
I do wonder to whom PMS matters.

It didn't matter to the eclass authors that littered them with "bad" bash 3.2 
features.

It didn't matter to QA when they were notified of that.

It didn't matter to council back then and is still not high up on their 
priority list.

Can it be that the general population of gentoo developers plainly don't care 
about PMS? And if we were to assume that were true, why would they do such a 
thing?

So many questions. Almost like those TV shows where you can win a million 
dollars or a flamingo or a new car.

>
> Of the small number of patches that have ended up being rejected from
> PMS, all but one have been yours, and the one that wasn't was because
> the author had mistranslated a phrase. I'd appreciate it if you would
> stop to consider why this is the case.
>
Well, I've not contributed to PMS (like most people) for a long time. Like 
other people I've known that ANY patch I contribute will be denied. Most other 
people don't have the curiosity that drives me to try it to prove my theory, 
so the number of PMS contributors is amazingly small.

Added to that it's atrocious language. Might have been better if native 
english speakers had written it, but beggars can't be choosers. Most people 
don't have the stamina to read it, much less find all the spots they'd need to 
clean up to have a small bit of functionality improved.

And then why bother when the tree doesn't reflect PMS. It's just futile to 
work on a "documentation" that gets the basics wrong. And as soon as you read 
up on prior discussions you find these exhausting discussions that go nowhere 
... why would any sane person want to spend time working on that? Much more 
fun to actually fix bugs or write ebuilds. Or play WoW or whatever.

But I digress. You didn't actually want to have an answer, that was most 
likely a rethorical question. Silly me taking things literally.

Anyway, chill out, enjoy Christmas,

Patrick