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

[Ciaran McCreesh]

On Mon, 1 Jul 2013 20:54:06 +0200
Arfrever Frehtes Taifersar Arahesis <arfrever.fta@×××××.com> 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.

To save time for people wanting to know how to vote, but who haven't
done the research, I'll give the correct answers here. This is just a
summary; for details, refer to the relevant bugs and previous
discussions which Arfrever helpfully cited.

Incidentally, it's probably unfair to ask candidates for their opinions
on matters that haven't made it past the PMS team. We've generally done
a fair amount of work on the technical details and implications of
proposals before passing them to the Council, and that work hasn't been
done on quite a few of these. It's not really very reasonable to expect
candidates to have put in a huge amount of work into this and every
other area when most of the EAPI 6 work will be handled at the team
level and passed up for approval.

Anyway, the answers:

The following are worth discussing, but are not a foregone conclusion
either way:

> 12. Will you vote for removing PORTDIR and ECLASSDIR variables in
> EAPI 6 (assuming that a patch is available for Portage)?

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

The following are probably the best thing to do from a long term
perspective, but are going to make some people whine an awful lot:

> 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)?

> 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)?

The following suggest we probably want a way of avoiding hardcoding
quite so much at some point:

> 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)?

> 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)?

The following should be treated with extreme caution, have unobvious
implications, need substantial work or are otherwise probably more
dangerous than they're worth, especially if we want EAPI 6 this year:

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

> 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)?

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

> 16. Will you vote for providing REPOSITORY variable 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)?

> 30. Will you vote for including support for src_fetch() function in
> EAPI 6 (assuming that a patch is available for Portage)?

The following proposals are very bad, and implementing them would be a
mistake:

> 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)?

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

The following are unimplementable, generally nonsense in their current
form ("wouldn't it be great if ebuilds could solve world hunger?"), not
EAPI or PMS related or otherwise beyond the scope of EAPI 6:

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

> 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)?

> 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)?

> 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)?

> 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)?

> 26. Will you vote for including support for transitive subslots in
> EAPI 6 (assuming that a patch is available for Portage)?

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

> 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)?

-- 
Ciaran McCreesh