ferringb at gmail
Nov 4, 2009, 8:56 PM
Post #1 of 4
(30 views)
Permalink
|
|
a pragmatic approach to FEATURES [was FEATURES use or misuse?]
|
|
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[at]gentoo.org> 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
|
signature.asc
