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

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

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 4836 bytes --]

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?

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.

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

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

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

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

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

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

12. Will you vote for removing PORTDIR and ECLASSDIR variables 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)?

14. Will you vote for allowing bash-4.2 features 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)?

17. Will you vote for including support for repository dependencies 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)?

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

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

27. Will you vote for including support for subslot dictionaries 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)?

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

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

--
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 5932 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Pacho Ramos]

El lun, 01-07-2013 a las 20:54 +0200, Arfrever Frehtes Taifersar
Arahesis escribió:
[...]
> 26. Will you vote for including support for transitive subslots in EAPI 6
>     (assuming that a patch is available for Portage)?

What are they? Thanks for the info!

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

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 317 bytes --]

2013-07-01 21:19 Pacho Ramos napisał(a):
> > 26. Will you vote for including support for transitive subslots in EAPI 6
> >     (assuming that a patch is available for Portage)?
> 
> What are they? Thanks for the info!

https://bugs.gentoo.org/show_bug.cgi?id=449094

--
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 591 bytes --]

On Mon, 01 Jul 2013 21:19:11 +0200
Pacho Ramos <pacho@gentoo.org> wrote:
> El lun, 01-07-2013 a las 20:54 +0200, Arfrever Frehtes Taifersar
> Arahesis escribió:
> [...]
> > 26. Will you vote for including support for transitive subslots in
> > EAPI 6 (assuming that a patch is available for Portage)?
> 
> What are they? Thanks for the info!

https://bugs.gentoo.org/show_bug.cgi?id=449094

I strongly suspect there's more to it than we realise. I'd like to see
a test implementation and some stuff using it experimentally before we
go any further...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 3976 bytes --]

2013-07-01 21:18 Ciaran McCreesh napisał(a):
> On Mon, 1 Jul 2013 20:54:06 +0200
> Arfrever Frehtes Taifersar Arahesis <arfrever.fta@gmail.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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/01/2013 09:18 PM, Ciaran McCreesh wrote:

This thread is for:
- - asking a nominee a question
- - participating in an argument with a nominee

So you are offtopic. Propagate your opinions on gentoo-user ML. This
thread is for questioning the nominees.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJR0eQDAAoJEFpvPKfnPDWz3NMH/jxxs5x0wRmN0W6nHIVxEwUa
0qRzaMquREZqSk+R/Z0rXlXwuk2GF29UvXKqYQDtvuoiXT3KArS0A5U2nKv6+/zn
GtRE0jJDMUGpQ6G58jEziKPCRiPZt6KIMEeapTCVIE0ffuCZRPwnSVrVFKzqncuC
UKMGfOoWWE1zp63/bmBS8jebsBbOUn3mOVQO9/YpxxknsFeaNYV8inpbSR0tJfvl
JE0XB9Z8eYTqLxclKr/8cNORkpnyS+zYC2Tz9nB4DjCTe/IIH3D8Zok89nasBNDU
awrDeMpqjPBBAsDr7f0nO+jEUKN0uQfx9zo1QZykeq67CHVlT3hSZTBq5Emagi8=
=H3sy
-----END PGP SIGNATURE-----

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2927 bytes --]

On Mon, 1 Jul 2013 21:56:02 +0200
Arfrever Frehtes Taifersar Arahesis <arfrever.fta@gmail.com> wrote:
> > 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?

For users, it's useful. But EAPIs have nothing to do with user-facing
features, and Paludis does not support this feature in a Gentoo EAPI.
There needs to be a discussion and policy on how exactly they're allowed
to be used if they're permitted in the tree.

> Already implemented in Portage (not in official EAPIs).

This as an argument for a feature is wrong in at least three ways.

Firstly, an implementation is sometimes necessary to see why something
isn't as good an idea as it initially looks.

Secondly, there's a big difference between having something implemented
in a package mangler, and having experience with that feature in the
tree. Being able to implement something is a necessary condition, not a
sufficient one.

Thirdly, an implementation of a feature for users is not the same as
allowing it in the tree.

Repository dependencies are a good example of all three of these
points. For users, they're useful (although the limited way Portage has
them implemented removes a lot of that). But in the tree they have
problems that we know about (see previous discussions that you like to
ignore when pushing for this feature) and probably some that we don't
too, since no-one's ever tried using them in the tree. We've already
established that repository dependencies in the tree are the wrong
solution, so you using "there's an implementation!" in their favour is
at best disingenuous.

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

The point of abolishing location variables is to allow things like
partial syncs, not to replace them with a slightly different thing that
imposes the same restrictions.

But again, if you're trying to advocate for any particular feature, you
should really discuss them on the relevant bugs, not try to use the
Council elections to subvert the process.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 01 Jul 2013 22:18:11 +0200
hasufell <hasufell@gentoo.org> wrote:
> On 07/01/2013 09:18 PM, Ciaran McCreesh wrote:
> 
> This thread is for:
> - - asking a nominee a question
> - - participating in an argument with a nominee
> 
> So you are offtopic. Propagate your opinions on gentoo-user ML. This
> thread is for questioning the nominees.

The gentoo-user list is not the place to discuss PMS / EAPI issues. Nor
are these election issues at this stage, since standard procedure is to
do a lot more work on these kinds of proposals before asking Council
members to invest their time on them. So the whole thread is merely an
attempt at bypassing the usual PMS / EAPI process, and it's best served
with a quick summary of the facts early on so nominees can avoid
having to waste their time doing the detailed research that would be
needed to provide answers on their own.

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iEYEARECAAYFAlHR6BkACgkQ96zL6DUtXhFPqQCgsAQ/YvmRK6AHzFpV+MpvjrqH
yMwAoN5uoSofjEG1TzHREjAqN4TTv0K/
=pSni
-----END PGP SIGNATURE-----

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

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 338 bytes --]

2013-07-01 22:35 Ciaran McCreesh napisał(a):
> So the whole thread is merely an attempt at bypassing the usual PMS / EAPI process

The purpose of this thread is to help each voter in voting by allowing to observe which
candidates have point of view similar to point of view of this voter.

--
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 455 bytes --]

2013-07-01 22:20 Ciaran McCreesh napisał(a):
> But again, if you're trying to advocate for any particular feature, you
> should really discuss them on the relevant bugs, not try to use the
> Council elections to subvert the process.

I do not advocate any particular feature in this thread. I might be even against some features.
Opinions of non-candidates (including you) are not needed in this thread.

--
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]

On Mon, 1 Jul 2013 23:14:05 +0200
Arfrever Frehtes Taifersar Arahesis <arfrever.fta@gmail.com> wrote:
> 2013-07-01 22:35 Ciaran McCreesh napisał(a):
> > So the whole thread is merely an attempt at bypassing the usual
> > PMS / EAPI process
> 
> The purpose of this thread is to help each voter in voting by
> allowing to observe which candidates have point of view similar to
> point of view of this voter.

That's a pretty dangerous purpose, since most of the issues you asked
about aren't simple enough for a "point of view" to tell you anything.
One of the interesting things about this problem domain is that often
there are right answers and wrong answers, and people's opinions don't
change whether or not something is impossible. I would be vary wary of
decisions made based upon "that sounds like a good idea from a one line
summary that didn't include references to the actual proposal and any
associated discussion"...

Or perhaps you were hoping candidates would reply "I'll defer becoming
involved in these issues until we receive the detailed proposals that
are usually provided to the Council when it comes to discussing EAPI
issues"? If so, it was a bit disingenuous to provide such a long list
of questions.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Theo Chatzimichos]

[-- Attachment #1: Type: text/plain, Size: 380 bytes --]

On Monday 01 of July 2013 23:23:37 Arfrever Frehtes Taifersar Arahesis wrote:
> Opinions of non-candidates (including you) are not
> needed in this thread.

Excellent logic! Opinions of non candidates are not needed in this thread! 
Which, by the way, is a thread with a shitload of questions to the candidates 
of the councils elections, from someone who is not eligible to vote!

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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@gentoo.org>

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1670 bytes --]

>>>>> On Mon, 1 Jul 2013, 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.

I'm going to answer the more general questions.

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

About one EAPI per year, on average.

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

They should be moved away from EAPI 0 at some point, but this needs to
be coordinated with their maintainers.

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

See previous answer.

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

Yes, after EAPI 6 has be accepted. We shouldn't have more than three
or four EAPIs in active use.

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

See previous answer. (So, "no" for the upcoming council term.)

Concerning your detailed (and sometimes very technical) questions 08
to 32 about EAPI 6, we already have a preliminary list of tentative
features [1], including some from your list that were rejected for
EAPI 5. This doesn't exclude that we add additional features to it,
but it shouldn't be too many if we want to finalise EAPI 6 this year
still. I'll make up my mind about the individual features when
concrete proposals are on the table.

Ulrich

[1] https://wiki.gentoo.org/wiki/Future_EAPI/EAPI_6_tentative_features

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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
(716) 829-8197

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]

On Tue, 02 Jul 2013 08:46:01 -0400
"Anthony G. Basile" <basile@opensource.dyc.edu> wrote:
> 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.

Uhm, really? State one legitimate use of available_eclasses as an EAPI
function.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Anthony G. Basile]

On 07/02/2013 08:46 AM, Anthony G. Basile wrote:
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
>

Sorry rereading this it got munged.

I meant to say

"while we allowed testing before transparently cutting over to 13.0"

and

"use.stable.mask and friends, but because this was a transparent 
cutover, ie no user had to switch profiles from ../10.0/... to 
../13.0/... via eselect profile, it just automatically happened one day 
(ie I did it behind the scenes), I needed to convince myself it would 
work without incident.  And it did."


-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

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

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 6104 bytes --]

Here is updated list of questions with fixes and added URLs.

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

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.

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

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

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

08. Will you vote for including support for version ranges in EAPI 6
    (assuming that a patch is available for Portage)?
    # https://bugs.gentoo.org/show_bug.cgi?id=4315
    # http://exherbo.org/docs/exheres-for-smarties.html#package_dependencies "Multiple version requirements"

09. Will you vote for including support for USE-flag-dependent slots in EAPI 6
    (assuming that a patch is available for Portage)?
    # https://bugs.gentoo.org/show_bug.cgi?id=174407

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)?
    # https://bugs.gentoo.org/show_bug.cgi?id=282296

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)?
    # https://bugs.gentoo.org/show_bug.cgi?id=373349

12. Will you vote for removing PORTDIR and ECLASSDIR variables in EAPI 6
    (assuming that a patch is available for Portage)?
    # https://bugs.gentoo.org/show_bug.cgi?id=373349
    # https://bugs.gentoo.org/show_bug.cgi?id=373351

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)?
    # https://bugs.gentoo.org/show_bug.cgi?id=399307

14. Will you vote for allowing bash-4.2 features in EAPI 6
    (assuming that a patch is available for Portage)?
    # https://bugs.gentoo.org/show_bug.cgi?id=431340

15. Will you vote for enabling globstar shell option by default in EAPI 6
    (assuming that a patch is available for Portage)?
    # https://bugs.gentoo.org/show_bug.cgi?id=414811

16. Will you vote for providing REPOSITORY variable in EAPI 6
    (assuming that a patch is available for Portage)?
    # https://bugs.gentoo.org/show_bug.cgi?id=414813

17. Will you vote for including support for repository dependencies in EAPI 6
    (assuming that a patch is available for Portage)?
    # https://bugs.gentoo.org/show_bug.cgi?id=414815

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)?
    # https://bugs.gentoo.org/show_bug.cgi?id=414817

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)?
    # https://bugs.gentoo.org/show_bug.cgi?id=424283
    # http://www.gentoo.org/proj/en/glep/glep-0062.html

20. Will you vote for including support for host/target-specific dependencies in EAPI 6
    (assuming that a patch is available for Portage)?
    # https://bugs.gentoo.org/show_bug.cgi?id=317337

21. Will you vote for including support for crosscompilation-specific
    dependencies in EAPI 6
    (assuming that a patch is available for Portage)?
    # https://bugs.gentoo.org/show_bug.cgi?id=317337

22. Will you vote for including support for DEPENDENCIES variable with labels in EAPI 6
    (assuming that a patch is available for Portage)?
    # http://exherbo.org/docs/exheres-for-smarties.html#dependencies

23. Will you vote for including support for labels in SRC_URI variable in EAPI 6
    (assuming that a patch is available for Portage)?
    # http://exherbo.org/docs/exheres-for-smarties.html#downloads

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)?
    # https://bugs.gentoo.org/show_bug.cgi?id=444568

25. Will you vote for including support for unique subslots for live ebuilds in EAPI 6
    (assuming that a patch is available for Portage)?
    # https://bugs.gentoo.org/show_bug.cgi?id=444366

26. Will you vote for including support for transitive subslots in EAPI 6
    (assuming that a patch is available for Portage)?
    # https://bugs.gentoo.org/show_bug.cgi?id=449094

27. Will you vote for including support for subslot dictionaries in EAPI 6
    (assuming that a patch is available for Portage)?
    # https://bugs.gentoo.org/show_bug.cgi?id=462138

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)?
    # https://bugs.gentoo.org/show_bug.cgi?id=423245

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)?
    # https://bugs.gentoo.org/show_bug.cgi?id=249086

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)?
    # https://bugs.gentoo.org/show_bug.cgi?id=311795

--
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 754 bytes --]

2013-07-02 14:51 Ciaran McCreesh napisał(a):
> On Tue, 02 Jul 2013 08:46:01 -0400
> "Anthony G. Basile" <basile@opensource.dyc.edu> wrote:
> > 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.
> 
> Uhm, really? State one legitimate use of available_eclasses as an EAPI
> function.

E.g. finding list of eclasses to be processed during installation of app-portage/eclass-manpages,
after dropping PORTDIR and ECLASSDIR.

--
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]

On Tue, 02 Jul 2013 08:46:01 -0400
"Anthony G. Basile" <basile@opensource.dyc.edu> wrote:

> On 07/01/2013 02:54 PM, Arfrever Frehtes Taifersar Arahesis wrote:

>  > 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".

Paweł was nice enough to write a patch for us to get toolchain.eclass up to EAPI
5.  I believe it still needs some pieces like prefix support and I haven't
reviewed it in depth but it looks good so far (and much simpler than I thought
(oops)).  I'm planning on moving up an EAPI at a time, bumping it whenever we
could use new features or people start hucking fruit.


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

>>>>> On Wed, 3 Jul 2013, Arfrever Frehtes Taifersar Arahesis wrote:

> 2013-07-02 14:51 Ciaran McCreesh napisał(a):
>> Uhm, really? State one legitimate use of available_eclasses as
>> an EAPI function.

> E.g. finding list of eclasses to be processed during installation of
> app-portage/eclass-manpages, after dropping PORTDIR and ECLASSDIR.

An ongoing council election is really not the right time for pushing
your EAPI 6 proposals. Also these technical matters are off-topic in
gentoo-project, so please take this discussion to gentoo-dev or
gentoo-pms.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Anthony G. Basile]

On 07/03/2013 01:42 AM, Ryan Hill wrote:
> On Tue, 02 Jul 2013 08:46:01 -0400
> "Anthony G. Basile" <basile@opensource.dyc.edu> wrote:
>
>> On 07/01/2013 02:54 PM, Arfrever Frehtes Taifersar Arahesis wrote:
>
>>   > 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".
>
> Paweł was nice enough to write a patch for us to get toolchain.eclass up to EAPI
> 5.  I believe it still needs some pieces like prefix support and I haven't
> reviewed it in depth but it looks good so far (and much simpler than I thought
> (oops)).  I'm planning on moving up an EAPI at a time, bumping it whenever we
> could use new features or people start hucking fruit.
>
>

Nice!  I'm impressed.

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

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

[Anthony G. Basile]

On 07/03/2013 12:37 AM, Arfrever Frehtes Taifersar Arahesis wrote:
> Here is updated list of questions with fixes and added URLs.
>


Arfrever, thanks for the clarification on those questions.  The bug 
report helped. For what its worth, here are the rest of my answers:


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

This would add support for syntax/semantics like this:

	SLOT="multislot? ( $PV ) !multislot? ( 0 )"

I don't know about this one.  My gut reaction is the same as Zac's, why 
not just unconditionally do SLOT="$PV".  I'm bothered by what it means 
for a user who might later drop USE="mutlislot", would we clean up all 
the older SLOTS?  I'm going to say no to this one unless there's a more 
pressing case made.

My general philosophy is to not just add features which address some 
issue but think about what other (ab)uses it might lead to.  I'm not 
sure this one won't open up a can of worms.



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

Okay, I misinterpreted this one.  Its a question of *directories* for 
these vs flat files.  I see no problem here.



18. Will you vote for including support for repository-specific
     package.use and {,package.}use{,.stable}.{force,mask} in EAPI 6

Okay in my last answer set, I misinterpreted 10 and my answer there is 
more relevant to 18 so let me briefly repeat it here:  I have mixed 
feelings about these configurations because they solve issues that occur 
with deep profile stackings whereas I prefer to encourage shallow 
profile stackings with orthogonal tweaks relegated to profile/features 
which can safely be added at the top (end) of the stack eg. 
profile/features/selinux.



15. Will you vote for enabling globstar shell option by default in EAPI 6

Yes.  On several occasions I've found myself wanting to do a `find ${D} 
-print` in some ebuild or script to locate, eg. .la files.  This reduces 
the need for the extra execution of find and does it in the shell.  It 
does required bash-4 so that needs to be approved first for this.



16. Will you vote for providing REPOSITORY variable in EAPI 6
17. Will you vote for including support for repository dependencies in 
EAPI 6

I agree with Michał and Ulrich here.  I don't want the behavior of 
ebuilds to change depending on repository.  Functional differences 
should be reflected in USE flags.  We should not be depending on which 
repository the ebuild lives in.



19. Will you vote for including support for optional run-time dependencies.

I would vote Yes.  I didn't know about glep 62 before but this is 
definitely a good feature and I can already see its usefulness for some 
packages I maintain where there would be useless rebuild if I were to 
drop USE="perl".  I can't see through the implementation details but if 
the PMS people think this is doable, then yes.  From a consumer point of 
view, it has no backwards compat issues and adds a feature which is well 
defined and useful.



20. Will you vote for including support for host/target-specific 
dependencies in EAPI 6
21. Will you vote for including support for crosscompilation-specific 
dependencies in EAPI 6

This is a tough one.  Distinguishing host dependencies from target 
dependencies is a legitimate issue and one which I've had to deal with 
myself.  However its clear from the discussion that there are semantic 
issues revolving around the meaning of the proposed 
DEPEND/TDEPEND/HDEPEND/BDEPEND etc.  The discussion is approaching 
clarity towards the end with Steve's and Mike's obersvation, and I'm 
siding with the
BDEPEND approach, but I'm not sure we're ready for inclusion in EAPI 6. 
A definite vote of "yes" for when its ready.

Incidentally the way I've dealt with this myself is always by manual 
hacks, ie, I run a cross-emerge until it breaks, I see why it breaks, I 
manually deal with the dependencies (or other issues).  Since I'm 
usually interested in just getting a seed to run catalyst on native 
hardware, I can live with my approach, but this is a real show stopper 
for a cross-emerge catalyst run.  Given that native hardware can be 
slow, we really want to get this fixed.



22. Will you vote for including support for DEPENDENCIES variable with 
labels in EAPI 6
23. Will you vote for including support for labels in SRC_URI variable 
in EAPI 6

I would not vote in favor of these.  While the first one is interesting, 
it deviates significantly from Gentoo's approach to dependencies and I 
don't see how it would fit in.  I'm less opposed to the second one, 
alhtough I don't see usefulness.  I don't like the label syntax, but 
that secondary since we could work through that
if we wanted this.

General statement: I'm not for radical changes which what I see in 
queston 22.  We do sometimes engineer ourselves into a corner and we 
have to struggle with that (eg. the meaning of *DEPEND in the previous 
question), but radical changes just means we engineer ourselves into 
dirrent corners while loosing what we've already done.



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

I'm with Zac on this one.  Why not do this in an eclass?  So "no" unless 
there's some mitigating reason why it can't be done elsewhere.



25. Will you vote for including support for unique subslots for live 
ebuilds in EAPI 6

This one is amusing.  -9999 are wild moving targets in the first place. 
  subslots are for when ABIs change in libraries without corresponding 
SONAME bumps, so this makes for an interesting combination.

I have no strong feelings against it since live ebuilds are not for end 
users but developers.  If you emerge one, then its up to you to know 
what you are doing.  Having said that, I can see how the subslotting 
might be helpful to us.

Aside: I'm not much of a fan of subslotting.  The situation where 
upstream changes ABIs without bumping SONAME represents a bug in the 
library which should not accommodate by a feature in our PMS.



26. Will you vote for including support for transitive subslots in EAPI 6

Given that subslotting is used to track library version dependency, I 
agree with Sergei's example.  I would support this but I'd like to 
eventually see the final details how this will be implemented.



27. Will you vote for including support for subslot dictionaries in EAPI 6

I had no idea about the independant bumps in the different ABIs of 
app-text/poppler.  I see the point to the need for this now.   I'm torn 
between the solution proposed by Arfrever (subslot dictionaries) and 
that by Zac (use of virtuals).  Zac's approach has the advantage that we 
don't introuce a new (abusable?) feature to the package specs.  Either 
way, packages like poppler are going to be maintenance burdens on 
maintainers who want to track the different internal ABI changes.  This 
is pitted against the current situation where users may be subjected to 
unnecesary rebuilds.  *shrug*  I'm not sure which side is the lesser evil.



28. Will you vote for including support for ico, svg, xhtml and xml files in

Yes.  Responding to points made in the bug: I say we include .ico files. 
  I have no strong opinions against backporting this with the -A or just 
including it in EAPI 6.



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

This sounds like a good idea but I have to be honest, I'm not sure what 
problems it might introduce.  So without doing an analysis of the tree 
right now, I'm going to say a soft "yes" contingent on gathering more 
information about what the consequences would be.


30. Will you vote for including support for src_fetch() function in EAPI 6

I'm not sure about this one.  Why can't the problem in bug #249086 not 
be solved in other ways?  What other uses would there be for a 
src_fetch()?  (The only uses coming to mind are stuff like `use amd64` 
for arch specific fetches but we can already do that.)

Also, I would be afraid of abuses, like live ebuild style fetching. 
Repository history can be rewritten, so just because you set a commit 
tag, doesn't guarantee stuff won't change on you.  I know this can and 
does happen with tarballs too, but I'd like to see QA checks in any 
implementation of src_fetch() against the kind of upstream changes that 
can occur in repositories.



31. Will you vote for including support for "." characters in package 
names in EAPI 6
32. Will you vote for including support for "." characters in USE flags 
in EAPI 6

I have no strong feelings either way.  If people want this and it isn't 
an implementation nightmare then okay.

    USE=i.can_t.wait.to.see.how.this.one.will.be.abused

The only negative I can think of right now is that this may clash with 
future semantics we may want to attribute to "." in either of those two 
contexts.  Like what if we want to formalize some meaning to sub-use 
flags as a better namespace approach rather than USE_EXPAND? 
USE="plugin.auth plugin.liana"  I don't know, just thinking out loud.


--Tony


-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

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

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Paweł was nice enough to write a patch for us to get toolchain.eclass up to EAPI
> 5.  I believe it still needs some pieces like prefix support and I haven't
> reviewed it in depth but it looks good so far (and much simpler than I thought
> (oops)).  I'm planning on moving up an EAPI at a time, bumping it whenever we
> could use new features or people start hucking fruit.
> 
> 
I would be forever in your debt if toolchain were on eapi 5 and had
proper subslot deps.

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR1yK8AAoJEKXdFCfdEflKCJYQAJFY4WAvmQLdPfVUsfhhAhoq
++hsVL1RB8QnX4C8NSAIpe7RMUPaNP9FYrVb2geFu8/x9+A5WBm6LCyZvA2TJiDC
v30r61Cwml7iu0sNRh2s7DtcYv/TUqqdxPuMLh5hNNMDW2/MuDSBJ90RkRHx0CCC
JBMfUTo7lsfF58yHst/NSuYYG06hG+cGB/KwvXHgLLzyh19Vrs9tx2nv/T8HbAYe
xUtVNylB+W3nxRVZe7tA2KcyVa7zVc/ygl5L/5g8uTpqGFnoLqzL6xO+1mcXtk80
5chyLg8SwbRK6RfV2KUC/Fffv2q26AMOiq3+atlVFmUeryqx41pODrG64UVuO6aE
m5mQ5oJ/5cTJAe8HpIxdlD1015Vp3D2BnJhc3EzimILSpxF+nlLN8wzrmBo14WZj
7EUnBgEftF7Raq+MeGL3UW1QFN9/uIzdmpPXQ4471WXq2qDv83ChFPwntZtZmApT
gtP9qsAbtGgiyWt5Uy2v81Hc/WnRv6KlzNauXdlGd6W3tSDd/Ga97M7EOif12Yl2
8isVMkLLOOqZysvF0Y7wwOicwXjaQs4WW+HMtkBE16rEH+B1ZxFEtHuhjfQ5WqtA
meVf8ob8gUUcblb+/3/v0H4uHHXqWAm6KY4ti8gc5havYwx+CjbBIe9ZHFU3lyeP
/r7VszCup/Pux3rCJwpv
=aIgV
-----END PGP SIGNATURE-----

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

[Tony Vroon]

On Fri, 2013-07-05 at 15:47 -0400, Rick "Zero_Chaos" Farina wrote:
> I would be forever in your debt if toolchain were on eapi 5 and had
> proper subslot deps.

It certainly sounds like a much better approach to incrementally improve
the toolchain eclass rather than trying to forcibly invalidate EAPI 0
through a council decree.
Once the actual use tapers off to where a removal makes sense... we may
still end up on a tree with minimum EAPI 5 this year. 

Regards,
Tony V.

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

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/05/2013 04:15 PM, Tony Vroon wrote:
> On Fri, 2013-07-05 at 15:47 -0400, Rick "Zero_Chaos" Farina wrote:
>> I would be forever in your debt if toolchain were on eapi 5 and had
>> proper subslot deps.
> 
> It certainly sounds like a much better approach to incrementally improve
> the toolchain eclass rather than trying to forcibly invalidate EAPI 0
> through a council decree.
> Once the actual use tapers off to where a removal makes sense... we may
> still end up on a tree with minimum EAPI 5 this year. 
> 

One of those rare days when I agree completely with chainsaw ;-)

Yes, trying to force toolchain to upgrade through the council is
suicidal, however, this thread seemed to indicate people actively
working on moving to eapi 5 without the council forcing them.  As there
isn't a council decree and things are still moving forward I figured it
would be helpful to show appreciation.  So as the lead developer for
Pentoo, as well as a member of Gentoo releng, thanks to those working on
getting toolchain updated to eapi 5, I believe this is be a major
improvement across many projects and many user's lives.

Thanks,
Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR1zVkAAoJEKXdFCfdEflKfS0P/1uzCcW/MyhCHiu4WkGGnnrd
WFh4hQxz0+SuMTTdSwn6Y1NopKftQGXCAd0Y1QMRkEImQntMeBPETJ4IPnbAZ901
+vR/+qJ+0zfm/DSQIe+fFoxuQWtN96KUtDypTV/1gOtbjzvKakMtFhkxyldDQ/sl
YGNgNCZQ4pwl4dx2lYQVAoB9GRSxRGNLRLGVOA3oiP5VRBoeUJNj7fOLF4flBQxq
vSz5IzIoXmvUEEWCBwf/g6PGXN8QNoQzemmWfI9yK8sV0e8Hbz0fORrxwlYIRY2K
jSy6X/jKss+i5cOJ/lach7qVflEgwqgZzDvELXULANDf06CrUEVtyGCMu7e/aR/2
NLc/8R6F6gunglUFLanSod8o+VJ5f1rQnKlslJIbezBcKcO6OwWeu0dhgde8N4Fk
WGSmiDVjViBQlMXK2Dn1oMI/0HSFIvF7SQMgoFkCcGC/euew4WFsFx3ZGq8PxeF2
UjN/kC0dXkbfWKfr4hSXBflUOQFDRVI+HbjeRJto+SRG81BSf3ZuuJd1r6bak/5U
kjKpxnCLacdkAMRFXWvVw4rgzlpDbpSzAXJ2CzAivUiLVYgjIDqvvglXaMiSg/yK
NvtmqDR+NmgnmYI7Xx69FOmSxDcpD6F23AHq5ogK1noi+1EoCeadyqs3uHGJ/rTy
Y6Z3+fp+KLAO2fB3/ORU
=NqQu
-----END PGP SIGNATURE-----

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

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 933 bytes --]

On Fri, 05 Jul 2013 15:47:08 -0400
"Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> > Paweł was nice enough to write a patch for us to get toolchain.eclass up to
> > EAPI 5.  I believe it still needs some pieces like prefix support and I
> > haven't reviewed it in depth but it looks good so far (and much simpler
> > than I thought (oops)).  I'm planning on moving up an EAPI at a time,
> > bumping it whenever we could use new features or people start hucking fruit.
> > 
> > 
> I would be forever in your debt if toolchain were on eapi 5 and had
> proper subslot deps.

What use case are you encountering?  I hadn't planned on using subslots, but
I'm open to good reasons/bribery.


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/05/2013 09:41 PM, Ryan Hill wrote:
> On Fri, 05 Jul 2013 15:47:08 -0400
> "Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>> Paweł was nice enough to write a patch for us to get toolchain.eclass up to
>>> EAPI 5.  I believe it still needs some pieces like prefix support and I
>>> haven't reviewed it in depth but it looks good so far (and much simpler
>>> than I thought (oops)).  I'm planning on moving up an EAPI at a time,
>>> bumping it whenever we could use new features or people start hucking fruit.
>>>
>>>
>> I would be forever in your debt if toolchain were on eapi 5 and had
>> proper subslot deps.
> 
> What use case are you encountering?  I hadn't planned on using subslots, but
> I'm open to good reasons/bribery.
> 
> 

Livecd builds work like this:

stage3 tarball is unpacked, then toolchain (minimum package set) is
built with ROOT=/tmp/stage1root and is linked to the original (seed
stage) while being built.

When we then move onto stage 2, it uses just the packages built during
stage1 (/tmp/stage1root becomes /).  This means, if seed stage has
mpc.so.0.1 but portage has since included mpc.so.2 that the gcc in
stage2 is linked against mpc.so.0.1 but only mpc.so.0.2 is installed.

To combat this kind of failure we are currently running "emerge --update
- --deep --newuse --complete-graph --rebuild-if-new-ver gcc" which could
just be "emerge --update gcc" if eapi 5 subslots were used properly.

Please forgive me if any of these details aren't perfect, I'm using my
best recollection of the most recent issue which happened when mpc was
bumped a few months ago.

I am available on irc quite a bit if you would like to discuss, however,
if you want to keep it on the ML we really need to move this to -dev.

Thanks,
Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR136KAAoJEKXdFCfdEflK1AcP/0uYADFi6lso1df+Us+Cq6T7
dKookGsH04P9ToOGttn4otZC0a0vYTtvYF45Ez9y+SnU5ra3jWV0TwjdTU1t+wUc
h7e/h9zlU2Vls/OskdnbwRdTzZACLd5feLzkAjfBrqGtSipi7gKqnyC/6eEaNuQJ
Tbv7fS8luNIgNyPA87EbVst3TR5ruKehjDwEOECYmuX9MicUO0m6uPmaO6O4xtbe
A1fmkbdvZqPKROnvUBOJPxGrMYWqvL3Z7qcl0bjDK/GOL8tudGPUvRLMf10auIu7
apfpLsv2xeDD0E4u+jx4+Z1mrS2g+L+11d6yz8cNhiduedcHfJKF+pkhTiHEXvzX
7RxSqq5jKfqW7nh+ACm1I7cLcioV+e6BIXYcp4sQnkoAIXy6D0bMm6ZdXpqDizI4
Zz8VMc+vyNKyhLB7g8L+34RX38wTc8DNDaXDHV7PCNsuj6JtMtXj0zCkkIlEUo9V
bHSX4jvXGGvMV9Bmih/91/69MieCgi2U6a0t4838KHdBxE7tg/3SET1a1axLNYAD
YsuHFaqDYXhmxjDywGBLD6XtReAOjhDnrRthc2kp6Oy5YeOwcl/k5ZV/ruYmA/m0
0ZfewBr+O2UTtLBqvKy1JVbxxeKWXKOzH7HdOfiLH90yDMIb63BNM++hKoMRFX3R
wqyiBLCnBevVjxF7jN7v
=8dF7
-----END PGP SIGNATURE-----