1 |
On 07/01/2013 02:54 PM, Arfrever Frehtes Taifersar Arahesis wrote: |
2 |
> All candidates for Gentoo Council 2013/2014 are asked to answer the following |
3 |
> technical questions, since Gentoo Council 2013/2014 will vote on at least |
4 |
> some of relevant propositions. |
5 |
|
6 |
|
7 |
Arfrever, thanks for these questions. Having read them, I take them as |
8 |
a learning opportunity into PMS. I do want to caution, however, that |
9 |
these are technical questions focusing on primarily on PMS. While this |
10 |
is important, I would also like to note that 1) technical questions |
11 |
beyond PMS as equally important, and 2) questions of community relations |
12 |
are urgent, although orthogonal to the technical problems. My area in |
13 |
gentoo is not in PMS although, as you know, I do contribute to portage |
14 |
(bug #465000) and to discussions about PMS (bug #458866). |
15 |
|
16 |
What tipped the scale for me regarding running for this position was 1) |
17 |
I have the time this up coming year without detracting from my other |
18 |
developing and 2) the social question. There are differing levels of |
19 |
skill and areas of expertise, but we all depend on one another to make |
20 |
gentoo go. There would be no projects/developers in gentoo if it |
21 |
weren't for every other project/developer in gentoo. How do we make |
22 |
that work? |
23 |
|
24 |
Having said that, here are my first set of answers. I will address the |
25 |
later ones once I've read and thought about the bugs that introduced the |
26 |
issue. Eg. q 27. subslot dictionaries! Wow, there's a mind twister. |
27 |
I can't imagine right now why I'd want this but ... okay ... I'll read |
28 |
that bug and respond. |
29 |
|
30 |
|
31 |
|
32 |
> 01. What interval (in months) between introductions of new EAPIs do |
33 |
you prefer? |
34 |
|
35 |
While everyone wants their shiny new features in the next EAPI, each |
36 |
EAPI brings enough global changes and I would rather error on the side |
37 |
of caution. In the absence of any urgent need, a one year cycle seems |
38 |
work. This is necessarily fuzziness because, for example, EAPI=3 added |
39 |
little and so could have been introduced on a tiny time scale. EAPI=5 |
40 |
with its change to profiles needed response from developers to act and |
41 |
so it needs a longer cycle. (We may be approaching the end of that one |
42 |
now). |
43 |
|
44 |
The more trackers you have to open to push through the changes, the more |
45 |
you depend on developers to act, the longer the cycle. |
46 |
|
47 |
|
48 |
|
49 |
> 02. Will you vote for moving system packages (gcc, glibc etc.) to |
50 |
EAPI >=3? |
51 |
> |
52 |
> 03. Will you vote for moving system packages (gcc, glibc etc.) to |
53 |
EAPI >=4? |
54 |
> |
55 |
> 04. Will you vote for moving system packages (gcc, glibc etc.) to |
56 |
EAPI >=5? |
57 |
> |
58 |
> 05. Will you vote for deprecation of EAPI 0 in gentoo-x86? |
59 |
|
60 |
Currently there is a lot of code written in EAPI 0 for the toolchain and |
61 |
this code "just works". Besides being able to build stock systems, it |
62 |
is cable of handling cross compiling, multlilib systems, toolchain |
63 |
hardening, and alternative libc. A lot of utilities are built on that |
64 |
codebase too, like crossdev. It is hard to argue a rewrite here for |
65 |
something that is not broken. |
66 |
|
67 |
I would not vote at this time for the deprecation of EPI 0. I could be |
68 |
persuaded otherwise by the toolchain herd with a plan. I could also be |
69 |
persuaded if there were some really pressing issues that argue "yes it |
70 |
works now, but soon will hit a brick wall". These would mitigate |
71 |
against a hard "no". |
72 |
|
73 |
A better approach would be to limit EAPI 0 to just a few eclasses and |
74 |
ebuilds, make sure that these play nicely with the latest sexy EAPIs and |
75 |
disallow/discourage EAPI 0 for anything else. In practice this is |
76 |
already being done as the arch teams stabilize packages and encourage |
77 |
bumps to the latest EAPI. |
78 |
|
79 |
|
80 |
|
81 |
> 06. Will you vote for deprecation of EAPI 3 in gentoo-x86? |
82 |
> |
83 |
> 07. Will you vote for deprecation of EAPI 4 in gentoo-x86? |
84 |
|
85 |
I don't mind seeing EAPI 3 deprecated in the near future. The prefix |
86 |
stuff which it added is pretty well integreate and nicely subsumed into 4. |
87 |
|
88 |
Deprecating EAPI 4 in favor of 5 is much more complex in light of the |
89 |
profile changes. Eg. This affected the hardened profiles which |
90 |
inherited the 10.0. I intentionally held back the switch to 13.0 for |
91 |
about 6 months while we allowed testing before transparently cutting |
92 |
over to 10.0. This may have been overly cautious because hardened |
93 |
doesn't have or currently need use.stable.mask and friends, but n |
94 |
|
95 |
|
96 |
> 08. Will you vote for including support for version ranges in EAPI 6 |
97 |
|
98 |
Version ranges of what? Packages. If so, this is fine. It is a |
99 |
generalization of >=cat/foo-3.3* or similar. I feel like I'm missing |
100 |
something more subtle here. |
101 |
|
102 |
|
103 |
|
104 |
> 09. Will you vote for including support for USE-flag-dependent slots |
105 |
in EAPI 6 |
106 |
|
107 |
I'm interpreting this as the following: I have a package with |
108 |
IUSE="foo". When I build with USE="-foo" then my package must depend on |
109 |
bar:1 but if USE="foo" then I must depend on bar:2. If so, we already |
110 |
have the syntax to do this, so why would we need this? |
111 |
|
112 |
This seems too simple, so I suspect I may be mis-interpreting this, and |
113 |
so correct me if I'm wrong. Let me make a general statement: I don't |
114 |
like feature creep. I don't like languages that allow you dozens of |
115 |
different ways to say the same thing. (Lary Wall forgive me!) I would |
116 |
resist the inclusion of new syntax for semantics that can already be |
117 |
expressed. I'm not sure I buy the argument "this is a more natural way |
118 |
of saying X". You learn how to say X in a language, you say X. |
119 |
|
120 |
|
121 |
|
122 |
10. Will you vote for including support for package.mask, package.use |
123 |
and {,package.}use{,.stable}.{force,mask} directories in EAPI 6 |
124 |
|
125 |
Yes. bug #414817. But I admit to having mixed feelings here. |
126 |
|
127 |
Let me give you an illustration of my concern: when I first looked at |
128 |
the selinux profiles back in 2009, we had a problem with |
129 |
amd64-nomultilib. The reason was that the way the stacking occurred it |
130 |
toggled the mutlilib flag on off and back on again. One approach would |
131 |
have been to make use of this family of profile settings to use.force |
132 |
the flags at the very top of the stack. The other would have been to |
133 |
completely remove selinux from the hardened profile stack structure and |
134 |
make it into features/selinux which is orthogonal to every other profile |
135 |
we have, not only hardened but the default (aka vanilla) profiles. I |
136 |
don't recall having the choice then, but I'm happy the way things turned |
137 |
out. So I'm afraid that these settings open up abuse in already complex |
138 |
profiles. I prefer to see shallow profiles with orthogonal features |
139 |
addable as units at the end. Features which encourage the opposite may |
140 |
be a necessary evil (I'm not convinced) but evil none the less. |
141 |
|
142 |
|
143 |
|
144 |
11. Will you vote for providing master_repositories(), |
145 |
repository_path(), available_eclasses(), eclass_path() and |
146 |
license_path() functions in EAPI 6 |
147 |
|
148 |
I read about them at |
149 |
http://dev.gentoo.org/~zmedico/portage/doc/ch05s03s09.html. No problem |
150 |
here, they are informational and good information too. |
151 |
|
152 |
|
153 |
|
154 |
12. Will you vote for removing PORTDIR and ECLASSDIR variables in EAPI 6 |
155 |
|
156 |
I need more information here. What problem does this solve? I cant see |
157 |
any advantages but lots of potential breakage. |
158 |
|
159 |
Where did this come from, I'm really curious! |
160 |
|
161 |
|
162 |
|
163 |
13. Will you vote for including support for automatic unpack |
164 |
dependencies (configurable in single location in repository) in EAPI 6 |
165 |
|
166 |
Yes. I've been bit by this a few times. The advantage of forcing |
167 |
developers to put in the dependency explicitly means they have control |
168 |
over whether they want to pull it in, but its hard to see how you could |
169 |
emerge without being able to unpack. |
170 |
|
171 |
Specifically, I'm thinking here of busybox. Suppose I don't want |
172 |
app-arch/gzip on my system, and will have busybox provide it, I may not |
173 |
want automatic dependency on gzip just because |
174 |
SRC_URI="...foo-x.y.z.tar.gz" However, if we are intelligent about |
175 |
"automatic unpack dependencies" then yes. And being intelligent here |
176 |
means a caveat about the fact that busybox is configurable, so ... yeah |
177 |
it can get sticky. |
178 |
|
179 |
|
180 |
14. Will you vote for allowing bash-4.2 features in EAPI 6 |
181 |
|
182 |
Hahah! Yes, I was bit by this one, bug #465000. I'd like to move in |
183 |
that direction because of the associated arrays that bash brings in. I |
184 |
understand that we need to keep backwards compat with bash 3 but I'm |
185 |
sure we can find an upgrade path, eg. intelligent wrappers switching on |
186 |
bash --version. Then when (at least) the 1 year backwards compat time |
187 |
expires, drop bash 3 and clean up. |
188 |
|
189 |
So a vote of yes, with contingency on 1 year backwards compat plan. |
190 |
|
191 |
|
192 |
Arfrever, this is long!!! I'll answer the rest later. I want to get |
193 |
working on some other stuff now and will answer the other questions later. |
194 |
|
195 |
--Tony |
196 |
|
197 |
|
198 |
-- |
199 |
Anthony G. Basile, Ph. D. |
200 |
Chair of Information Technology |
201 |
D'Youville College |
202 |
Buffalo, NY 14201 |
203 |
(716) 829-8197 |