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

[Brian Dolbec]

Just let me preface my answers with:

Any OPINION, I state (briefly) below, is a starting point for
discussions and implementations that would lead to a final decision
being made.  A "Final" decision will always be based on the facts
present/known at the time such a decision is to be made.

In other words, they aren't chiseled into stone.  As I've not been a
member of the council. I have also not gotten involved too deeply into
many of the past issues.  Instead I have concentrated my efforts on
coding.  Keep in mind that I do not do a lot of ebuild work.  The
majority of my work is done in python coding for many of the tools used
in maintaining your gentoo install.  It is those tools that will need
work to implement those features and changes.  It is more than just
portage's code that is affected.   As there are few of us doing the work
on those tools.  Council decisions should not be overzealous in
approving too many of them at any one time.

While I am responding to some of these questions, many of them I have no
opinion of so far.  Nor do I have enough knowledge about them to make
informed opinions.  But I do feel that it is important to answer many of
them.  Despite that the only 2 people pushing the questions have no vote
in the election...  Many are valid questions other qualified voters
might like to know our answers to.


On Mon, 2013-07-01 at 20:54 +0200, 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.
>
> (Non-candidates are asked to not start any discussions in this thread.)
>
> 01. What interval (in months) between introductions of new EAPIs do you prefer?
>

A minimum of 6 months, preferably 1 year.  Too many, too quickly and it
creates too much confusion with both devs and users.  It also gives more
time to ensure the implementation is done correctly.

> 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?
>
>     # EAPIs 1 and 2 are currently deprecated in gentoo-x86.
>     # Deprecation of an EAPI in gentoo-x86 has no effect to what is supported by
>     # package managers and what is described in PMS.
>

where appropriate, yes all the way up to eapi 5.  I not long ago patched
catalyst code to work around the lack of eapi 5 system pkgs with correct
subslot assignments.  The libmpc upgrade broke the use of gcc binaries
and binpkgs.  Causing delayed failures that were not readily apparent.

As the 13.0 profile requires a minimum of an EAPI 5 capable package
manager.  Once the other profiles are also up to that level and a
reasonable amount of time has past to update systems.  I see no reason
to not start migrating them.  Yes there is a danger of breaking upgrade
paths for machines not updated often.  But Gentoo as a whole has
endeavored to maintain an upgrade path for a reasonable amount of time.
I see that continuing, even for system pkgs.



> 05. Will you vote for deprecation of EAPI 0 in gentoo-x86?
>

Quite possibly, but no final decision made.  I'm open to arguments on
both sides.

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

Probably a bit too early for these.  Let's get one (EAPI 0) fully
deprecated first.  NEEDINFO

> 08. Will you vote for including support for version ranges in EAPI 6
>     (assuming that a patch is available for Portage)?
>

 NEEDINFO

> 09. Will you vote for including support for USE-flag-dependent slots in EAPI 6
>     (assuming that a patch is available for Portage)?
>

 NEEDINFO, but this is sounding like slots getting out of control


> 10. Will you vote for including support for package.mask, package.use
>     and {,package.}use{,.stable}.{force,mask} directories in EAPI 6
>     (assuming that a patch is available for Portage)?
>

 NEEDINFO, but given convincing arguments for it, possibly

> 11. Will you vote for providing master_repositories(), repository_path(),
>     available_eclasses(), eclass_path() and license_path() functions in EAPI 6
>     (assuming that a patch is available for Portage)?
>

 NEEDINFO

> 12. Will you vote for removing PORTDIR and ECLASSDIR variables in EAPI 6
>     (assuming that a patch is available for Portage)?
>
 NEEDINFO, I know portage is moving away from PORTDIR and
PORTDIR_OVERLAY variable usage in make.conf  to the repos.conf format.

> 13. Will you vote for including support for automatic unpack dependencies
>     (configurable in single location in repository) in EAPI 6
>     (assuming that a patch is available for Portage)?
>

I'm not against nor for it at this point.   NEEDINFO

> 14. Will you vote for allowing bash-4.2 features in EAPI 6
>     (assuming that a patch is available for Portage)?
>

Probably, but I have not viewed all the facts for both sides at this
point in time.

> 15. Will you vote for enabling globstar shell option by default in EAPI 6
>     (assuming that a patch is available for Portage)?
>
I never heard of globstar before.  NEEDINFO

> 16. Will you vote for providing REPOSITORY variable in EAPI 6
>     (assuming that a patch is available for Portage)?
>
> 17. Will you vote for including support for repository dependencies in EAPI 6
>     (assuming that a patch is available for Portage)?
>

I am not sold on this as a viable solution to many problems.  It could
help support use of overlays better, but having not seen any
implementation proposals...  NEEDINFO  Only proposal I've seen along
these lines is your feature request for layman to nearly become a
package manager and handle repository dependencies.  Where both myself
and infra rejected it.  At least your moving in the right direction by
wanting it in the package manager now.


> 18. Will you vote for including support for repository-specific
>     package.use and {,package.}use{,.stable}.{force,mask} in EAPI 6
>     (assuming that a patch is available for Portage)?
>
repeat of question 10

> 19. Will you vote for including support for optional run-time dependencies
>     controlled by run-time-switchable USE flags (GLEP 62) in EAPI 6
>     (assuming that a patch is available for Portage)?
>

I'll read up on the glep

> 20. Will you vote for including support for host/target-specific dependencies in EAPI 6
>     (assuming that a patch is available for Portage)?
>
> 21. Will you vote for including support for crosscompilation-specific
>     dependencies in EAPI 6
>     (assuming that a patch is available for Portage)?
>

I have not had the need to do crosscompilation or host/target work, so
can not give you an informed opinion about this.

> 22. Will you vote for including support for DEPENDENCIES variable with labels in EAPI 6
>     (assuming that a patch is available for Portage)?
>
> 23. Will you vote for including support for labels in RESTRICT variable in EAPI 6
>     (assuming that a patch is available for Portage)?
>

labels in a unified DEPENDENCIES variable I think would be a good thing
provided the implementation was done correctly.  I know from past email
threads there was a bunch of debate about it.  Prove your case for your
favorite implementation.  Being consistent about labels in other
variables is good design.  But I'm sure that will be a hot topic arguing
over which implementation is good design and which one is "crap".


> 24. Will you vote for exporting XDG_CACHE_HOME, XDG_CONFIG_HOME, XDG_DATA_HOME
>     and XDG_RUNTIME_DIR variables (with useful values) in EAPI 6
>     (assuming that a patch is available for Portage)?
>
> 25. Will you vote for including support for unique subslots for live ebuilds in EAPI 6
>     (assuming that a patch is available for Portage)?
>
> 26. Will you vote for including support for transitive subslots in EAPI 6
>     (assuming that a patch is available for Portage)?
>

I think this is an important topic for subslots development.  NEEDINFO

> 27. Will you vote for including support for subslot dictionaries in EAPI 6
>     (assuming that a patch is available for Portage)?
>

as previously described... "but this is sounding like slots getting out
of control"

> 28. Will you vote for including support for ico, svg, xhtml and xml files in
>     dohtml in EAPI 6
>     (assuming that a patch is available for Portage)?
>
> 29. Will you vote for disallowing diropts(), docompress(), exeopts(), insopts(),
>     keepdir(), libopts(), use(), use_enable(), use_with(), useq(), usev() and usex()
>     functions in global scope in EAPI 6
>     (assuming that a patch is available for Portage)?
>
> 30. Will you vote for including support for src_fetch() function in EAPI 6
>     (assuming that a patch is available for Portage)?
>

NEEDINFO

> 31. Will you vote for including support for "." characters in package names in EAPI 6
>     (assuming that a patch is available for Portage)?
>
> 32. Will you vote for including support for "." characters in USE flags in EAPI 6
>     (assuming that a patch is available for Portage)?
>

You have had code in portage for this for a long time now. It's been
what 2 years already? perhaps longer...   It is a feature you added for
your progress overlay and eclasses.  This will also affect many other
tools.  Not just portage.  As you have not been able to persuade any
other councils for this.  What makes you think it will be different this
time?

> --
> Arfrever Frehtes Taifersar Arahesis


Anyway, I hope this is enough for now to get things rolling into a
decent NON-BIKESHEDING NON-flame throwing, thread.

-- 
Brian Dolbec <dolsen@g.o>