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

[Arfrever Frehtes Taifersar Arahesis]

2013-07-01 21:18 Ciaran McCreesh napisał(a):
> 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.

Your answers are not necessarily correct and sometimes contradict each other.

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

Already implemented in Paludis (not in official EAPIs).
Is it a mistake that Paludis supports this feature?

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

Already implemented in Portage (not in official EAPIs).

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

Already implemented in Portage (not in official EAPIs).

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

Already implemented in Portage (not in official EAPIs).

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

This feature provides multiple-repository-friendly replacement for
single-repository-specific PORTDIR and ECLASSDIR variables.
Already implemented in Portage (not in official EAPIs).

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

Already implemented in Portage (not in official EAPIs).

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

Already implemented in 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)?

Already implemented in Portage (not in official EAPIs).

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

Partially implemented in Portage (not in official EAPIs).

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

Already implemented in Portage (not in official EAPIs).

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

Already implemented in Portage (not in official EAPIs).

--
Arfrever Frehtes Taifersar Arahesis