1 |
On Wed, Nov 04, 2009 at 07:36:17PM -0600, Ryan Hill wrote: |
2 |
> On Wed, 4 Nov 2009 09:26:10 +0100 |
3 |
> have a core portage dev on record, saying "FEATURES are not supposed to have |
4 |
> an effect on the package itself, just how portage handles the package. |
5 |
> Packages behaving differently on certain FEATURES settings are considered |
6 |
> broken by me" back in 2005, before PMS was even a glimmer in an ex-gentoo |
7 |
> dev's eye. |
8 |
|
9 |
Marius was always quite a bit more hardline about FEATURES then the |
10 |
rest of us, but he never did have an answer for the harder questions |
11 |
about FEATURES. Stubbs/myself were more pragmatic- in a purely |
12 |
academic sense FEATURES shouldn't exist, but we actually want to get |
13 |
shit done so bite the bullet and jump in with the pigs till a better |
14 |
solution is found. |
15 |
|
16 |
Off the top of my head, I don't recall carpaski ever giving a damn |
17 |
about ebuild access to FEATURES either, although you'd have to ask |
18 |
him. |
19 |
|
20 |
So you have another core developer from the same era saying "stop |
21 |
being academic and start being pragmatic". Also, get me some pie. |
22 |
|
23 |
To make it clear- lots of people say things. Saying something doesn't |
24 |
make it right nor make it viable. Cliche, but it seems to need |
25 |
repeating since people are latching onto a 4-5 year old comment as if |
26 |
it were the word of law. |
27 |
|
28 |
And if that's not enough to shut people up, consider splitdebug, |
29 |
strip, noman, nodoc, sandbox (yes some ebuilds have had to be aware of |
30 |
it), test, etc. |
31 |
|
32 |
Every one of those features influences packages in ways that at times |
33 |
requires the ebuild to be aware of it, and the majority of that list |
34 |
predate eapi/pms. For some, there were solutions that didn't involve |
35 |
a hasq on $FEATURES, but not for all (preserve-libs and splitdebug |
36 |
come to mind). |
37 |
|
38 |
|
39 |
> Patrick Lauer <patrick@g.o> wrote: |
40 |
> > The only reason it was not properly documented in PMS was because the |
41 |
> > authors didn't agree with it. |
42 |
> |
43 |
> Bullshit. It wasn't documented in PMS because PMS doesn't document user |
44 |
> configuration, because PMS shouldn't document user configuration. User |
45 |
> configuration is implementation specific. |
46 |
|
47 |
That's a mighty fine line to draw. Pkgcore supports wildly different |
48 |
configurations, but still has a FEATURES var it exports to the user |
49 |
env. This was done because ebuilds *expect* FEATURES to be there for |
50 |
some of the screwier things that exist. Point being, user |
51 |
configuration *should not* be part of PMS, but that doesn't mean you |
52 |
can just label FEATURES as user config and stick your fingers in your |
53 |
ears because you don't like it's existance. |
54 |
|
55 |
I'm not saying I like that fact- I don't particularly like FEATURES. |
56 |
That said, it *is* a fact it's out there. If you're going to argue |
57 |
that ebuilds shouldn't know of FEATURES in some fashion, I suggest |
58 |
you finish that arguement and say that the majority of RESTRICT |
59 |
should be pruned (there is a fair amount of parity between the two). |
60 |
|
61 |
|
62 |
> Do you not realize what a pain in |
63 |
> the ass it would be if we had to do an EAPI bump to slightly change the |
64 |
> semantics of "userpriv" or to change the enabled defaults, not to mention |
65 |
> change any of the environment variables portage uses for configuration? |
66 |
> Making these things independent of the specification allows the package |
67 |
> manager the freedom it needs to make the changes it needs to in order to |
68 |
> continue improving, and frankly, allows other implementations to be something |
69 |
> other than simple portage clones. |
70 |
|
71 |
Ebuilds being aware that a space delimited var named FEATURES exists |
72 |
does not mean that PMS has to document each/every FEATURE. |
73 |
|
74 |
If in doubt, consider that PMS doesn't document the installed pkg |
75 |
database (at all), but makes the barest mention required. Or consider |
76 |
RESTRICT. Same deal. In certain spots, PMS seems willing to document |
77 |
the barest bits needed for something while in others it just ignores |
78 |
their existance (always found that annoying I might add). |
79 |
|
80 |
From a purely academic standpoint, FEATURES shouldn't be available to |
81 |
ebuilds. I'd suggest that for those pushing the academic route they |
82 |
find equivalent solutions that are of roughly comparable |
83 |
implementation cost for the ebuild dev, and push those changes |
84 |
through out the tree (after getting the maintainers consent of |
85 |
course). |
86 |
|
87 |
Prove it flies for all scenarioes. They want the changes primarily, |
88 |
and PMS choose to remove FEATURES from eapi0, they do the legwork |
89 |
rather then forcing it via a spec. |
90 |
|
91 |
|
92 |
From a more pragmatic stance, I suggest the following- |
93 |
|
94 |
1) FEATURES for existing EAPI's is documented as a space delimited |
95 |
variable that is effectively an array of 'enabled' |
96 |
features/flags/whatever you want to call them. By enabled I mean the |
97 |
barest restriction on the items in the list- can't start with '-' |
98 |
(this is due to the incremental nature of FEATURES from configs- it's |
99 |
not really a requirement, just basically reality that no FEATURE item |
100 |
will start with '-'). |
101 |
|
102 |
2) the contents of FEATURES, the possibilities for flag/feature names |
103 |
are left to PM implementation details. |
104 |
|
105 |
Yes this can become a mess. I'm well aware it would require paludis |
106 |
to export a var they hate, although realistically for the way users |
107 |
hook functionality in they ought to be able to do a simple append to |
108 |
the ebuild env w/out issue. |
109 |
|
110 |
If this were done, it would also require the 3 pms to cooperate on |
111 |
the naming of what specific functionality would be named. |
112 |
ccache/distcc/sandbox/preserve-libs/userpriv being the main ones that |
113 |
come to mind. Even if they didn't, the ebuild author would have the |
114 |
option of either leveling a block, or just tweaking their hasq to |
115 |
check for an extra name. Annoying, but pragmatic. |
116 |
|
117 |
3) via pulling it in and more importantly acknowledging it's |
118 |
existance, it opens up the potential for later EAPI's to change it- |
119 |
say mandating in EAPI3 that an ebuild must not do 'hasq sandbox |
120 |
$FEATURES', instead doing '[ -n "$SANDBOX_ON" ]'. |
121 |
|
122 |
|
123 |
Stats time: |
124 |
|
125 |
Currently, 96 ebuilds out of 26825 directly reference FEATURES via a |
126 |
fairly tight grep- of those, we're talking about dbus, mysql, libc, |
127 |
sqlite, postgres, mythtv, mono, and gcc. |
128 |
|
129 |
These are not podunk packages. At least for gcc/glibc, they've got |
130 |
good reasons for the checks they're doing- I'm not aware of |
131 |
alternatives for those cases. |
132 |
|
133 |
For eclasses, around 4% of the eclasses have a reference to |
134 |
FEATURES... they're minor ones like python, selinux-policy-2, |
135 |
toolchain, mysql, java-utils2, and oh yeah, eutils. |
136 |
|
137 |
Via |
138 |
pquery --attr inherited --raw --all --repo /usr/portage \ |
139 |
| cut -d= -f2- \ |
140 |
| egrep '( |")(eutils|gnatbuild|java-utils|kmod|mysql|myth|python|selinux-policy-2|toolchain(-binutils)?)( |")' \ |
141 |
| wc -l |
142 |
|
143 |
We get the happy number of 20220, roughly 75% of the tree. I'm not |
144 |
going to do the work, but if someone wants to filter that count down |
145 |
to just ebuilds that actually touch FEATURES codepath wise, that stat |
146 |
would be useful (and also a bit of a pain in the ass to get I |
147 |
suspect). |
148 |
|
149 |
Either way, academic doesn't seem incredibly sane when we're talking |
150 |
about worst case 75% of the largest (and realistically, core) |
151 |
repository of that format. |
152 |
|
153 |
Perhaps the pragmatic approach might be wise. |
154 |
|
155 |
Donned my absestos suit, so flame way ;) |
156 |
~harring |