Re: [gentoo-project] Questions for candidates for Gentoo Council 2013/2014

[Anthony G. Basile]

On 07/01/2013 02:54 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> All candidates for Gentoo Council 2013/2014 are asked to answer the following
> technical questions, since Gentoo Council 2013/2014 will vote on at least
> some of relevant propositions.


Arfrever, thanks for these questions.  Having read them, I take them as 
a learning opportunity into PMS.  I do want to caution, however, that 
these are technical questions focusing on primarily on PMS.  While this 
is important, I would also like to note that 1) technical questions 
beyond PMS as equally important, and 2) questions of community relations 
are urgent, although orthogonal to the technical problems.  My area in 
gentoo is not in PMS although, as you know, I do contribute to portage 
(bug #465000) and to discussions about PMS (bug #458866).

What tipped the scale for me regarding running for this position was 1) 
I have the time this up coming year without detracting from my other 
developing and 2) the social question.  There are differing levels of 
skill and areas of expertise, but we all depend on one another to make 
gentoo go.  There would be no projects/developers in gentoo if it 
weren't for every other project/developer in gentoo.  How do we make 
that work?

Having said that, here are my first set of answers.  I will address the 
later ones once I've read and thought about the bugs that introduced the 
issue.  Eg. q 27.  subslot dictionaries!  Wow, there's a mind twister. 
I can't imagine right now why I'd want this but ... okay ... I'll read 
that bug and respond.



 > 01. What interval (in months) between introductions of new EAPIs do 
you prefer?

While everyone wants their shiny new features in the next EAPI, each 
EAPI brings enough global changes and I would rather error on the side 
of caution.  In the absence of any urgent need, a one year cycle seems 
work.  This is necessarily fuzziness because, for example, EAPI=3 added 
little and so could have been introduced on a tiny time scale.  EAPI=5 
with its change to profiles needed response from  developers to act and 
so it needs a longer cycle.  (We may be approaching the end of that one 
now).

The more trackers you have to open to push through the changes, the more 
you depend on developers to act, the longer the cycle.



 > 02. Will you vote for moving system packages (gcc, glibc etc.) to 
EAPI >=3?
 >
 > 03. Will you vote for moving system packages (gcc, glibc etc.) to 
EAPI >=4?
 >
 > 04. Will you vote for moving system packages (gcc, glibc etc.) to 
EAPI >=5?
 >
 > 05. Will you vote for deprecation of EAPI 0 in gentoo-x86?

Currently there is a lot of code written in EAPI 0 for the toolchain and 
this code "just works".  Besides being able to build stock systems, it 
is cable of handling cross compiling, multlilib systems, toolchain 
hardening, and alternative libc.  A lot of utilities are built on that 
codebase too, like crossdev.  It is hard to argue a rewrite here for 
something that is not broken.

I would not vote at this time for the deprecation of EPI 0.  I could be 
persuaded otherwise by the toolchain herd with a plan.  I could also be 
persuaded if there were some really pressing issues that argue "yes it 
works now, but soon will hit a brick wall".  These would mitigate 
against a hard "no".

A better approach would be to limit EAPI 0 to just a few eclasses and 
ebuilds, make sure that these play nicely with the latest sexy EAPIs and 
disallow/discourage EAPI 0 for anything else.  In practice this is 
already being done as the arch teams stabilize packages and encourage 
bumps to the latest EAPI.



 > 06. Will you vote for deprecation of EAPI 3 in gentoo-x86?
 >
 > 07. Will you vote for deprecation of EAPI 4 in gentoo-x86?

I don't mind seeing EAPI 3 deprecated in the near future.  The prefix 
stuff which it added is pretty well integreate and nicely subsumed into 4.

Deprecating EAPI 4 in favor of 5 is much more complex in light of the 
profile changes.  Eg. This affected the hardened profiles which 
inherited the 10.0.  I intentionally held back the switch to 13.0 for 
about 6 months while we allowed testing before transparently cutting 
over to 10.0.  This may have been overly cautious because hardened 
doesn't have or currently need use.stable.mask and friends, but n


 > 08. Will you vote for including support for version ranges in EAPI 6

Version ranges of what?  Packages.  If so, this is fine.  It is a 
generalization of >=cat/foo-3.3* or similar.   I feel like I'm missing 
something more subtle here.



 > 09. Will you vote for including support for USE-flag-dependent slots 
in EAPI 6

I'm interpreting this as the following:  I have a package with 
IUSE="foo".  When I build with USE="-foo" then my package must depend on 
bar:1 but if USE="foo" then I must depend on bar:2.  If so, we already 
have the syntax to do this, so why would we need this?

This seems too simple, so I suspect I may be mis-interpreting this, and 
so correct me if I'm wrong.  Let me make a general statement: I don't 
like feature creep.  I don't like languages that allow you dozens of 
different ways to say the same thing. (Lary Wall forgive me!)  I would 
resist the inclusion of new syntax for semantics that can already be 
expressed.  I'm not sure I buy the argument "this is a more natural way 
of saying X".  You learn how to say X in a language, you say X.



10. Will you vote for including support for package.mask, package.use
     and {,package.}use{,.stable}.{force,mask} directories in EAPI 6

Yes.  bug #414817.  But I admit to having mixed feelings here.

Let me give you an illustration of my concern: when I first looked at 
the selinux profiles back in 2009, we had a problem with 
amd64-nomultilib.  The reason was  that the way the stacking occurred it 
toggled the mutlilib flag on off and back on again.  One approach would 
have been to make use of this family of profile settings to use.force 
the flags at the very top of the stack.  The other would have been to 
completely remove selinux from the hardened profile stack structure and 
make it into features/selinux which is orthogonal to every other profile 
we have, not only hardened but the default (aka vanilla) profiles.  I 
don't recall having the choice then, but I'm happy the way things turned 
out.  So I'm afraid that these settings open up abuse in already complex 
profiles.  I prefer to see shallow profiles with orthogonal features 
addable as units at the end.  Features which encourage the opposite may 
be a necessary evil (I'm not convinced) but evil none the less.



11. Will you vote for providing master_repositories(), 
repository_path(),  available_eclasses(), eclass_path() and 
license_path() functions in EAPI 6

I read about them at 
http://dev.gentoo.org/~zmedico/portage/doc/ch05s03s09.html.  No problem 
here, they are informational and good information too.



12. Will you vote for removing PORTDIR and ECLASSDIR variables in EAPI 6

I need more information here.  What problem does this solve?  I cant see 
any advantages but lots of potential breakage.

Where did this come from, I'm really curious!



13. Will you vote for including support for automatic unpack 
dependencies  (configurable in single location in repository) in EAPI 6

Yes.  I've been bit by this a few times.  The advantage of forcing 
developers to put in the dependency explicitly means they have control 
over whether they want to pull it in, but its hard to see how you could 
emerge without being able to unpack.

Specifically, I'm thinking here of busybox.  Suppose I don't want 
app-arch/gzip on my system, and will have busybox provide it, I may not 
want automatic dependency on gzip just because 
SRC_URI="...foo-x.y.z.tar.gz"  However, if we are intelligent about 
"automatic unpack dependencies" then yes.  And being intelligent here 
means a caveat about the fact that busybox is configurable, so ... yeah 
it can get sticky.


14. Will you vote for allowing bash-4.2 features in EAPI 6

Hahah!  Yes, I was bit by this one, bug #465000.  I'd like to move in 
that direction because of the associated arrays that bash brings in.  I 
understand that we need to keep backwards compat with bash 3 but I'm 
sure we can find an upgrade path, eg. intelligent wrappers switching on 
bash --version.  Then when (at least) the 1 year backwards compat time 
expires, drop bash 3 and clean up.

So a vote of yes, with contingency on 1 year backwards compat plan.


Arfrever, this is long!!! I'll answer the rest later.  I want to get 
working on some other stuff now and will answer the other questions later.

--Tony


-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
[phone]