[gentoo-dev] a pragmatic approach to FEATURES [was FEATURES use or misuse?]

[Brian Harring]

On Wed, Nov 04, 2009 at 07:36:17PM -0600, Ryan Hill wrote:
> On Wed, 4 Nov 2009 09:26:10 +0100
> have a core portage dev on record, saying "FEATURES are not supposed to have
> an effect on the package itself, just how portage handles the package.
> Packages behaving differently on certain FEATURES settings are considered
> broken by me" back in 2005, before PMS was even a glimmer in an ex-gentoo
> dev's eye.

Marius was always quite a bit more hardline about FEATURES then the 
rest of us, but he never did have an answer for the harder questions 
about FEATURES.  Stubbs/myself were more pragmatic- in a purely 
academic sense FEATURES shouldn't exist, but we actually want to get 
shit done so bite the bullet and jump in with the pigs till a better 
solution is found.

Off the top of my head, I don't recall carpaski ever giving a damn 
about ebuild access to FEATURES either, although you'd have to ask 
him.

So you have another core developer from the same era saying "stop 
being academic and start being pragmatic".  Also, get me some pie.

To make it clear- lots of people say things.  Saying something doesn't 
make it right nor make it viable.  Cliche, but it seems to need 
repeating since people are latching onto a 4-5 year old comment as if 
it were the word of law.

And if that's not enough to shut people up, consider splitdebug, 
strip, noman, nodoc, sandbox (yes some ebuilds have had to be aware of 
it), test, etc.

Every one of those features influences packages in ways that at times 
requires the ebuild to be aware of it, and the majority of that list 
predate eapi/pms.  For some, there were solutions that didn't involve 
a hasq on $FEATURES, but not for all (preserve-libs and splitdebug 
come to mind).


> Patrick Lauer <patrick@g.o> wrote:
> > The only reason it was not properly documented in PMS was because the
> > authors didn't agree with it.
>
> Bullshit.  It wasn't documented in PMS because PMS doesn't document user
> configuration, because PMS shouldn't document user configuration.  User
> configuration is implementation specific.

That's a mighty fine line to draw.  Pkgcore supports wildly different 
configurations, but still has a FEATURES var it exports to the user 
env.  This was done because ebuilds *expect* FEATURES to be there for 
some of the screwier things that exist.  Point being, user 
configuration *should not* be part of PMS, but that doesn't mean you 
can just label FEATURES as user config and stick your fingers in your 
ears because you don't like it's existance.

I'm not saying I like that fact- I don't particularly like FEATURES.  
That said, it *is* a fact it's out there.  If you're going to argue 
that ebuilds shouldn't know of FEATURES in some fashion, I suggest 
you finish that arguement and say that the majority of RESTRICT
should be pruned (there is a fair amount of parity between the two).


> Do you not realize what a pain in
> the ass it would be if we had to do an EAPI bump to slightly change the
> semantics of "userpriv" or to change the enabled defaults, not to mention
> change any of the environment variables portage uses for configuration?
> Making these things independent of the specification allows the package
> manager the freedom it needs to make the changes it needs to in order to
> continue improving, and frankly, allows other implementations to be something
> other than simple portage clones.

Ebuilds being aware that a space delimited var named FEATURES exists 
does not mean that PMS has to document each/every FEATURE.

If in doubt, consider that PMS doesn't document the installed pkg 
database (at all), but makes the barest mention required.  Or consider 
RESTRICT.  Same deal.  In certain spots, PMS seems willing to document 
the barest bits needed for something while in others it just ignores 
their existance (always found that annoying I might add).

From a purely academic standpoint, FEATURES shouldn't be available to 
ebuilds.  I'd suggest that for those pushing the academic route they 
find equivalent solutions that are of roughly comparable 
implementation cost for the ebuild dev, and push those changes 
through out the tree (after getting the maintainers consent of 
course).

Prove it flies for all scenarioes.  They want the changes primarily, 
and PMS choose to remove FEATURES from eapi0, they do the legwork 
rather then forcing it via a spec.


From a more pragmatic stance, I suggest the following-

1) FEATURES for existing EAPI's is documented as a space delimited 
variable that is effectively an array of 'enabled' 
features/flags/whatever you want to call them.  By enabled I mean the 
barest restriction on the items in the list- can't start with '-' 
(this is due to the incremental nature of FEATURES from configs- it's 
not really a requirement, just basically reality that no FEATURE item 
will start with '-').

2) the contents of FEATURES, the possibilities for flag/feature names 
are left to PM implementation details.

Yes this can become a mess.  I'm well aware it would require paludis 
to export a var they hate, although realistically for the way users 
hook functionality in they ought to be able to do a simple append to 
the ebuild env w/out issue.

If this were done, it would also require the 3 pms to cooperate on 
the naming of what specific functionality would be named.  
ccache/distcc/sandbox/preserve-libs/userpriv being the main ones that 
come to mind.  Even if they didn't, the ebuild author would have the 
option of either leveling a block, or just tweaking their hasq to 
check for an extra name.  Annoying, but pragmatic.

3) via pulling it in and more importantly acknowledging it's 
existance, it opens up the potential for later EAPI's to change it- 
say mandating in EAPI3 that an ebuild must not do 'hasq sandbox 
$FEATURES', instead doing '[ -n "$SANDBOX_ON" ]'.  


Stats time:

Currently, 96 ebuilds out of 26825 directly reference FEATURES via a 
fairly tight grep- of those, we're talking about dbus, mysql, libc, 
sqlite, postgres, mythtv, mono, and gcc.

These are not podunk packages.  At least for gcc/glibc, they've got 
good reasons for the checks they're doing- I'm not aware of 
alternatives for those cases.

For eclasses, around 4% of the eclasses have a reference to 
FEATURES... they're minor ones like python, selinux-policy-2, 
toolchain, mysql, java-utils2, and oh yeah, eutils.

Via 
pquery --attr inherited --raw --all --repo /usr/portage \
| cut -d= -f2- \
| egrep '( |")(eutils|gnatbuild|java-utils|kmod|mysql|myth|python|selinux-policy-2|toolchain(-binutils)?)( |")' \
| wc -l

We get the happy number of 20220, roughly 75% of the tree.  I'm not 
going to do the work, but if someone wants to filter that count down 
to just ebuilds that actually touch FEATURES codepath wise, that stat 
would be useful (and also a bit of a pain in the ass to get I 
suspect).

Either way, academic doesn't seem incredibly sane when we're talking 
about worst case 75% of the largest (and realistically, core) 
repository of that format.

Perhaps the pragmatic approach might be wise.

Donned my absestos suit, so flame way ;)
~harring