[gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC

[gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC

[Fabian Groffen]

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

The next council meeting will be on Tuesday 14 August 2012 at 19:00
UTC [1] in the #gentoo-council channel on Freenode.

Proposed agenda:

1. Intro / Roll call (5 minutes)

2. EAPI5 features (10 minutes)
   (no link, archives is not up-to-date, gmane misses the mail, marc
   doesn't have gentoo-project, mail by ulm in reply to dilfridge on 21st
   of July)
   * vote on the tentative list of EAPI 5 features
     (ulm: please provide said list)

3. Open bugs with Council involvement (0 minutes)
   * There are currently no open Council bugs

4. Open floor (10 minutes)


[1] http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900


-- 
Fabian Groffen
Gentoo on a different level

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

Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC

[Ulrich Mueller]

>>>>> On Tue, 7 Aug 2012, Fabian Groffen wrote:

> 2. EAPI5 features (10 minutes)
>    (no link, archives is not up-to-date, gmane misses the mail, marc
>    doesn't have gentoo-project, mail by ulm in reply to dilfridge on 21st
>    of July)
>    * vote on the tentative list of EAPI 5 features
>      (ulm: please provide said list)

Sorry for the delay. The list of candidates for EAPI 5 is included
below. I've grouped them into four categories:


First, features where a preliminary wording of the spec is already
available, and that don't seem to be controversial:

* Slot operator dependencies
  http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=f9f7729c047300e1924ad768a49c660e12c2f906
  https://bugs.gentoo.org/show_bug.cgi?id=229521

* Profile IUSE injection
  http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=d9040ab3482af5f790368bac5d053bf1cd760ba8
  https://bugs.gentoo.org/show_bug.cgi?id=176467

* Remove IMAGE variable
  http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=489a60deede1a0d78edb545e97b0e17addaa6ab4
  https://bugs.gentoo.org/show_bug.cgi?id=373377

* At-most-one-of operator for REQUIRED_USE
  http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=1c2dff2df2305aff88a734e3a2716de1bb69f3b6
  https://bugs.gentoo.org/show_bug.cgi?id=354219

* EBUILD_PHASE_FUNC variable
  http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=76ddca560da42fd968c53a2a0c38a6ac840a7ad4
  https://bugs.gentoo.org/show_bug.cgi?id=390765

* Mandate GNU find
  http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=472690942e14f63f1b1f3a5681976a59539ea3f8
  https://bugs.gentoo.org/show_bug.cgi?id=384157

* new* commands can read from standard input
  http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=4939df8586c7b17b03d8627a8371c988f4445a26
  https://bugs.gentoo.org/show_bug.cgi?id=263565

* Parsing of the EAPI assignment is mandatory
  http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=91d1e1e39b034bde7e5b981a5616a127135f37fa

* src_test support for parallel tests
  http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=3ec4b3c22582a8ec206bce1e93bab377d7b264b5
  https://bugs.gentoo.org/show_bug.cgi?id=363005

* Stable use forcing and masking
  http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=2921080e5b4f67ae55d2f80f8fea2b8d47ced831


Second, features where a spec hasn't been written yet, but which look
easy:

* doheader helper function
  https://bugs.gentoo.org/show_bug.cgi?id=21310

* usex helper function
  https://bugs.gentoo.org/show_bug.cgi?id=382963

* has_version and best_version argument for ROOT
  https://bugs.gentoo.org/show_bug.cgi?id=401239


Third, things where I think that some additional discussion is needed:

* econf --disable-silent-rules
  - Doesn't seem controversial for EAPI 5.
  - It has been suggested that this is applied retroactively to EAPI 4.
  http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=b7750e67b4772c1064543defb7df6a556f09807b
  https://bugs.gentoo.org/show_bug.cgi?id=379497

* User patches
  - Current wording of the spec requires that every ebuild includes a
    call to the apply_user_patches_here function in src_prepare.
    A alternative would be to apply user patches after src_prepare as
    a default, if the ebuild doesn't call the respective function.
  - Are we happy with the name apply_user_patches_here?
    (epatch_user? euserpatch?)
  http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=a8bf7862967cce36b7f1b408934a774126da2538<

* License groups in ebuilds
  - A simpler solution would be create separate license files like
    GPL-2+ for the few cases where this is needed. This would have the
    advantage that it could be applied to all EAPIs.
  https://bugs.gentoo.org/show_bug.cgi?id=287192

* EJOBS variable
  - Discussion was almost 4 years ago. Is there (still) consensus?
  http://archives.gentoo.org/gentoo-dev/msg_750e33f68b16d971dff1f40dd9145e56.xml


Finally, not sure if the following is a candidate for EAPI 5, or
should be postponed to EAPI 6:

* Cross-compile support
  http://archives.gentoo.org/gentoo-project/msg_b1e2b88bbeb667a3fa834c99a1981fbe.xml


Ulrich

Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC

[Michał Górny]

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

On Sun, 12 Aug 2012 23:05:04 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> * User patches
>   - Current wording of the spec requires that every ebuild includes a
>     call to the apply_user_patches_here function in src_prepare.
>     A alternative would be to apply user patches after src_prepare as
>     a default, if the ebuild doesn't call the respective function.
>   - Are we happy with the name apply_user_patches_here?
>     (epatch_user? euserpatch?)
>   http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=a8bf7862967cce36b7f1b408934a774126da2538<

I would like to add one more point here:
- The spec doesn't provide any kind of epatch function, so we will end
  up having two copies of epatch, one for user patches, and the other
  (from eclass) for ebuilds.


-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC

[hasufell]

On 08/12/2012 11:05 PM, Ulrich Mueller wrote:
>>>>>> On Tue, 7 Aug 2012, Fabian Groffen wrote:
> 
> Third, things where I think that some additional discussion is needed:
> 
> * econf --disable-silent-rules
>   - Doesn't seem controversial for EAPI 5.
>   - It has been suggested that this is applied retroactively to EAPI 4.
>   http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=b7750e67b4772c1064543defb7df6a556f09807b
>   https://bugs.gentoo.org/show_bug.cgi?id=379497
> 

Please note that this is only one of 3 suggestions:

1. apply it for EAPI=5
2. apply it for EAPI>=4
3. apply it for all EAPIs

Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC

[Arfrever Frehtes Taifersar Arahesis]

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

2012-08-12 23:05:04 Ulrich Mueller napisał(a):
> >>>>> On Tue, 7 Aug 2012, Fabian Groffen wrote:
> 
> > 2. EAPI5 features (10 minutes)
> >    (no link, archives is not up-to-date, gmane misses the mail, marc
> >    doesn't have gentoo-project, mail by ulm in reply to dilfridge on 21st
> >    of July)
> >    * vote on the tentative list of EAPI 5 features
> >      (ulm: please provide said list)
> 
> Sorry for the delay. The list of candidates for EAPI 5 is included
> below. I've grouped them into four categories:
> 
> 
> First, features where a preliminary wording of the spec is already
> available, and that don't seem to be controversial:
> 
> * Slot operator dependencies
>   http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=f9f7729c047300e1924ad768a49c660e12c2f906
>   https://bugs.gentoo.org/show_bug.cgi?id=229521
> 
> * Profile IUSE injection
>   http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=d9040ab3482af5f790368bac5d053bf1cd760ba8
>   https://bugs.gentoo.org/show_bug.cgi?id=176467
> 
> * Remove IMAGE variable
>   http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=489a60deede1a0d78edb545e97b0e17addaa6ab4
>   https://bugs.gentoo.org/show_bug.cgi?id=373377
> 
> * At-most-one-of operator for REQUIRED_USE
>   http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=1c2dff2df2305aff88a734e3a2716de1bb69f3b6
>   https://bugs.gentoo.org/show_bug.cgi?id=354219
> 
> * EBUILD_PHASE_FUNC variable
>   http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=76ddca560da42fd968c53a2a0c38a6ac840a7ad4
>   https://bugs.gentoo.org/show_bug.cgi?id=390765
> 
> * Mandate GNU find
>   http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=472690942e14f63f1b1f3a5681976a59539ea3f8
>   https://bugs.gentoo.org/show_bug.cgi?id=384157
> 
> * new* commands can read from standard input
>   http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=4939df8586c7b17b03d8627a8371c988f4445a26
>   https://bugs.gentoo.org/show_bug.cgi?id=263565
> 
> * Parsing of the EAPI assignment is mandatory
>   http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=91d1e1e39b034bde7e5b981a5616a127135f37fa
> 
> * src_test support for parallel tests
>   http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=3ec4b3c22582a8ec206bce1e93bab377d7b264b5
>   https://bugs.gentoo.org/show_bug.cgi?id=363005
> 
> * Stable use forcing and masking
>   http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=2921080e5b4f67ae55d2f80f8fea2b8d47ced831
> 
> 
> Second, features where a spec hasn't been written yet, but which look
> easy:
> 
> * doheader helper function
>   https://bugs.gentoo.org/show_bug.cgi?id=21310
> 
> * usex helper function
>   https://bugs.gentoo.org/show_bug.cgi?id=382963
> 
> * has_version and best_version argument for ROOT
>   https://bugs.gentoo.org/show_bug.cgi?id=401239

You forgot about the following features (already implemented in Portage):

* package.mask, use.force, use.mask, package.use, package.use.force and package.use.mask directories
  https://bugs.gentoo.org/show_bug.cgi?id=282296

* REPOSITORY variable
  https://bugs.gentoo.org/show_bug.cgi?id=414813

* Repository dependencies
  https://bugs.gentoo.org/show_bug.cgi?id=414815

* make.defaults, use.force, use.mask, package.use, package.use.force and package.use.mask in ${repository_path}/profiles
  https://bugs.gentoo.org/show_bug.cgi?id=414817

* Extended default list of extensions in dohtml
  https://bugs.gentoo.org/show_bug.cgi?id=423245

-- 
Arfrever Frehtes Taifersar Arahesis

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

Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC

[Michał Górny]

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

On Sun, 12 Aug 2012 23:05:04 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Tue, 7 Aug 2012, Fabian Groffen wrote:
> 
> > 2. EAPI5 features (10 minutes)
> >    (no link, archives is not up-to-date, gmane misses the mail, marc
> >    doesn't have gentoo-project, mail by ulm in reply to dilfridge
> > on 21st of July)
> >    * vote on the tentative list of EAPI 5 features
> >      (ulm: please provide said list)
> 
> Sorry for the delay. The list of candidates for EAPI 5 is included
> below. I've grouped them into four categories:
>
> [...]
>
> Second, features where a spec hasn't been written yet, but which look
> easy:

* Source eclasses only once
  https://bugs.gentoo.org/show_bug.cgi?id=422533

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC

[Zac Medico]

On 08/12/2012 02:05 PM, Ulrich Mueller wrote:
> First, features where a preliminary wording of the spec is already
> available, and that don't seem to be controversial:
> 
> * Slot operator dependencies
>   http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=f9f7729c047300e1924ad768a49c660e12c2f906
>   https://bugs.gentoo.org/show_bug.cgi?id=229521

We could easily extend SLOT operator dependencies to support sub-slots,
as implemented in EAPI 4-slot-abi:

http://blogs.gentoo.org/zmedico/2012/06/23/automatic-rebuilds-with-experimental-eapi-4-slot-abi/
http://dev.gentoo.org/~zmedico/portage/doc/portage.html#package-ebuild-eapi-4-slot-abi

It's been tested in the axs overlay:

http://git.overlays.gentoo.org/gitweb/?p=dev/axs.git
https://bugs.gentoo.org/show_bug.cgi?id=424429

-- 
Thanks,
Zac

Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC

[Ciaran McCreesh]

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

On Tue, 14 Aug 2012 09:02:02 +0200
Arfrever Frehtes Taifersar Arahesis <arfrever.fta@gmail.com> wrote:
> * package.mask, use.force, use.mask, package.use, package.use.force
> and package.use.mask directories
> https://bugs.gentoo.org/show_bug.cgi?id=282296

> * make.defaults, use.force, use.mask, package.use, package.use.force
> and package.use.mask in ${repository_path}/profiles
> https://bugs.gentoo.org/show_bug.cgi?id=414817

These two need a profiles EAPI bump, and we've not discussed what
happens when profiles go over EAPI 1 yet.

> * REPOSITORY variable
>   https://bugs.gentoo.org/show_bug.cgi?id=414813
> 
> * Repository dependencies
>   https://bugs.gentoo.org/show_bug.cgi?id=414815

These two are widely considered undesirable. The second one also has a
rather large "we don't agree on what it means, but whatever it means
it isn't want you naively want" issue.

-- 
Ciaran McCreesh

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

Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC

[Ulrich Mueller]

>>>>> On Sun, 12 Aug 2012, Ulrich Mueller wrote:

> The list of candidates for EAPI 5 is included below.

Here is an updated list, based on the replies to my original message.

First, features where a preliminary wording of the spec is already
available, and that don't seem to be controversial:

* Slot operator dependencies
  http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=f9f7729c047300e1924ad768a49c660e12c2f906
  https://bugs.gentoo.org/show_bug.cgi?id=229521

* Profile IUSE injection
  http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=d9040ab3482af5f790368bac5d053bf1cd760ba8
  https://bugs.gentoo.org/show_bug.cgi?id=176467

* Remove IMAGE variable
  http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=489a60deede1a0d78edb545e97b0e17addaa6ab4
  https://bugs.gentoo.org/show_bug.cgi?id=373377

* At-most-one-of operator for REQUIRED_USE
  http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=1c2dff2df2305aff88a734e3a2716de1bb69f3b6
  https://bugs.gentoo.org/show_bug.cgi?id=354219

* EBUILD_PHASE_FUNC variable
  http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=76ddca560da42fd968c53a2a0c38a6ac840a7ad4
  https://bugs.gentoo.org/show_bug.cgi?id=390765

* Mandate GNU find
  http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=472690942e14f63f1b1f3a5681976a59539ea3f8
  https://bugs.gentoo.org/show_bug.cgi?id=384157

* new* commands can read from standard input
  http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=4939df8586c7b17b03d8627a8371c988f4445a26
  https://bugs.gentoo.org/show_bug.cgi?id=263565

* Parsing of the EAPI assignment is mandatory
  http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=91d1e1e39b034bde7e5b981a5616a127135f37fa

* src_test support for parallel tests
  http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=3ec4b3c22582a8ec206bce1e93bab377d7b264b5
  https://bugs.gentoo.org/show_bug.cgi?id=363005

* Stable use forcing and masking
  http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=2921080e5b4f67ae55d2f80f8fea2b8d47ced831


Second, features where a spec hasn't been written yet, but which look
easy:

* doheader helper function
  https://bugs.gentoo.org/show_bug.cgi?id=21310

* usex helper function
  https://bugs.gentoo.org/show_bug.cgi?id=382963

* has_version and best_version argument for ROOT
  https://bugs.gentoo.org/show_bug.cgi?id=401239


Third, things where I think that some additional discussion is needed:

* econf --disable-silent-rules
  - Doesn't seem controversial for EAPI 5.
  - It has been suggested that this is applied retroactively, either
    for EAPI 4 only, or for all EAPIs.
  http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=b7750e67b4772c1064543defb7df6a556f09807b
  https://bugs.gentoo.org/show_bug.cgi?id=379497

* Extend SLOT operator dependencies to support sub-slots
  - As suggested by zmedico.
  http://blogs.gentoo.org/zmedico/2012/06/23/automatic-rebuilds-with-experimental-eapi-4-slot-abi/
  http://dev.gentoo.org/~zmedico/portage/doc/portage.html#package-ebuild-eapi-4-slot-abi
  https://bugs.gentoo.org/show_bug.cgi?id=424429

* User patches
  - Current wording of the spec requires that every ebuild includes a
    call to the apply_user_patches function in src_prepare.
    A alternative would be to apply user patches after src_prepare as
    a default, if the ebuild doesn't call the respective function.
  - The spec doesn't provide any kind of epatch function, so we will
    end up having two copies of epatch, one for user patches, and the
    other (from eclass) for ebuilds.
  - Are we happy with the name apply_user_patches?
    (epatch_user? euserpatch?)
  http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=a8bf7862967cce36b7f1b408934a774126da2538<

* License groups in ebuilds
  - A simpler solution would be create separate license files like
    GPL-2+ for the few cases where this is needed. This would have the
    advantage that it could be applied to all EAPIs.
  https://bugs.gentoo.org/show_bug.cgi?id=287192

* EJOBS variable
  - Discussion was almost 4 years ago. Is there (still) consensus?
  http://archives.gentoo.org/gentoo-dev/msg_750e33f68b16d971dff1f40dd9145e56.xml

* Source eclasses only once
  https://bugs.gentoo.org/show_bug.cgi?id=422533
  http://marc.info/?l=gentoo-dev&m=134493783816587&w=2

* Extended default list of extensions in dohtml
  - Objections against inclusion of non-standard extensions like .ico
    have been raised.
  https://bugs.gentoo.org/show_bug.cgi?id=423245

* REPOSITORY variable
  - Controversial, see bug.
  https://bugs.gentoo.org/show_bug.cgi?id=414813

* Repository dependencies
  - Controversial, see bug.
  https://bugs.gentoo.org/show_bug.cgi?id=414815


Finally, not sure if the following are candidates for EAPI 5:

* Cross-compile support
  http://archives.gentoo.org/gentoo-project/msg_b1e2b88bbeb667a3fa834c99a1981fbe.xml

* package.mask, use.force, use.mask, package.use, package.use.force
  and package.use.mask directories
  - Need profiles EAPI bump
  https://bugs.gentoo.org/show_bug.cgi?id=282296

* make.defaults, use.force, use.mask, package.use, package.use.force
  and package.use.mask in ${repository_path}/profiles
  - Need profiles EAPI bump
  https://bugs.gentoo.org/show_bug.cgi?id=414817


Ulrich

Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC

[Richard Yao]

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

On 08/14/2012 10:01 AM, Ulrich Mueller wrote:
> * Mandate GNU find
>   http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=472690942e14f63f1b1f3a5681976a59539ea3f8
>   https://bugs.gentoo.org/show_bug.cgi?id=384157

This will cause problems for Gentoo FreeBSD, which uses FreeBSD's find.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC

[Richard Yao]

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

On 08/14/2012 12:09 PM, Richard Yao wrote:
> On 08/14/2012 10:01 AM, Ulrich Mueller wrote:
>> * Mandate GNU find
>>   http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=472690942e14f63f1b1f3a5681976a59539ea3f8
>>   https://bugs.gentoo.org/show_bug.cgi?id=384157
> 
> This will cause problems for Gentoo FreeBSD, which uses FreeBSD's find.
> 

ulm pointed out that aliases are in
/var/cvsroot/gentoo-x86/profiles/default/bsd/fbsd/profile.bashrc, which
I did not know about. This will not cause any problems for Gentoo/FreeBSD.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC

[Andreas K. Huettel]

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

Am Dienstag, 14. August 2012, 16:01:57 schrieb Ulrich Mueller:
>
> * make.defaults, use.force, use.mask, package.use, package.use.force
>   and package.use.mask in ${repository_path}/profiles
>   - Need profiles EAPI bump
>   https://bugs.gentoo.org/show_bug.cgi?id=414817
> 

With that in mind I'd like to propose that this feature is uncoupled from any 
EAPI and discussed separately as add-on for all EAPI's. 

Reason: it adds only new files, and does not modify the meaning of anything 
existing. Waiting for a profile EAPI increase seems to be something like 
waiting for Sankt Nimmerleinstag (in German, waiting for the nameday of a 
saint that does not actually exist, i.e. hopelessly waiting forever).

Follow-up discussion on PMS please. 

-- 
Andreas K. Huettel
Gentoo Linux developer 
kde (team lead), sci, tex, arm, printing
dilfridge@gentoo.org
http://www.akhuettel.de/

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

Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC

[Ciaran McCreesh]

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

On Tue, 14 Aug 2012 23:17:56 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
> Waiting for a profile EAPI increase seems to be
> something like waiting for Sankt Nimmerleinstag (in German, waiting
> for the nameday of a saint that does not actually exist, i.e.
> hopelessly waiting forever).

The only reason all this takes so long is because getting anything done
with EAPIs involves wasting months dealing with people who demand to
know why their favourite unicorn isn't there yet, why the EAPI process
isn't what they want it to be, why EAPIs have to exist at all, why we
have to care about stability, why we have to change things, why we
can't change things, etc etc.

If getting things quickly is a goal, then you should ask the Council to
look into reducing the amount of public discussion and concensus that's
necessary to deliver a new EAPI.

-- 
Ciaran McCreesh

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

Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC

[Zac Medico]

On 08/14/2012 02:35 PM, Ciaran McCreesh wrote:
> On Tue, 14 Aug 2012 23:17:56 +0200
> "Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
>> Waiting for a profile EAPI increase seems to be
>> something like waiting for Sankt Nimmerleinstag (in German, waiting
>> for the nameday of a saint that does not actually exist, i.e.
>> hopelessly waiting forever).
> 
> The only reason all this takes so long is because getting anything done
> with EAPIs involves wasting months dealing with people who demand to
> know why their favourite unicorn isn't there yet, why the EAPI process
> isn't what they want it to be, why EAPIs have to exist at all, why we
> have to care about stability, why we have to change things, why we
> can't change things, etc etc.
> 
> If getting things quickly is a goal, then you should ask the Council to
> look into reducing the amount of public discussion and concensus that's
> necessary to deliver a new EAPI.

It seems like there's some confusion here. Approving a new EAPI and
deciding to use a new EAPI in a given profile are two entirely different
things. If we want to us a new EAPI in a profile, we just have to deploy
it such that users are only exposed to that profile when they
consciously running `eselect profile` (and they can always revert back
to the previous profile if it turns out that their installed package
manager doesn't support the new profile).
-- 
Thanks,
Zac

Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC

[Ciaran McCreesh]

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

On Tue, 14 Aug 2012 14:55:47 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> It seems like there's some confusion here. Approving a new EAPI and
> deciding to use a new EAPI in a given profile are two entirely
> different things. If we want to us a new EAPI in a profile, we just
> have to deploy it such that users are only exposed to that profile
> when they consciously running `eselect profile` (and they can always
> revert back to the previous profile if it turns out that their
> installed package manager doesn't support the new profile).

There's still the issue that we haven't decided what [use] deps do when
they show up in profile files. We were sticking at 1 until we worked
that out.

(Personally I'm in favour of just not allowing use deps anywhere in
profiles, and requiring package manglers to enforce it.)

-- 
Ciaran McCreesh

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

Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC

[Zac Medico]

On 08/14/2012 03:02 PM, Ciaran McCreesh wrote:
> On Tue, 14 Aug 2012 14:55:47 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>> It seems like there's some confusion here. Approving a new EAPI and
>> deciding to use a new EAPI in a given profile are two entirely
>> different things. If we want to us a new EAPI in a profile, we just
>> have to deploy it such that users are only exposed to that profile
>> when they consciously running `eselect profile` (and they can always
>> revert back to the previous profile if it turns out that their
>> installed package manager doesn't support the new profile).
> 
> There's still the issue that we haven't decided what [use] deps do when
> they show up in profile files. We were sticking at 1 until we worked
> that out.
> 
> (Personally I'm in favour of just not allowing use deps anywhere in
> profiles, and requiring package manglers to enforce it.)

That sounds reasonable to me.
-- 
Thanks,
Zac

Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC

[Michał Górny]

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

On Tue, 14 Aug 2012 23:02:04 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Tue, 14 Aug 2012 14:55:47 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
> > It seems like there's some confusion here. Approving a new EAPI and
> > deciding to use a new EAPI in a given profile are two entirely
> > different things. If we want to us a new EAPI in a profile, we just
> > have to deploy it such that users are only exposed to that profile
> > when they consciously running `eselect profile` (and they can always
> > revert back to the previous profile if it turns out that their
> > installed package manager doesn't support the new profile).
> 
> There's still the issue that we haven't decided what [use] deps do
> when they show up in profile files. We were sticking at 1 until we
> worked that out.

Ah, about that. It will be useful if [use] deps in package.mask worked
unlike in package.use.mask, thus giving us a tool to temporarily mask
packages which are broken only with given flags.

For example, likely it was potentially useful to do something like:

    # something support with intel broken in this version
    =media-libs/mesa-N.N.N[someflag,video_cards_intel,!video_cards_radeon,!video_cards_nvidia]

With meaning: mask mesa-N.N.N if 'someflag' and 'video_cards_intel' are
enabled, and 'video_cards_radeon' an 'video_cards_nvidia' are disabled.

This will make lives easier both for devs (who wouldn't have to
work-around this) and users (for those who will benefit from new mesa,
and those who will not upgrade and break their systems).

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC

[Andreas K. Huettel]

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

Am Dienstag, 14. August 2012, 23:55:47 schrieb Zac Medico:
> It seems like there's some confusion here. Approving a new EAPI and
> deciding to use a new EAPI in a given profile are two entirely different
> things. If we want to us a new EAPI in a profile, we just have to deploy
> it such that users are only exposed to that profile when they
> consciously running `eselect profile` (and they can always revert back
> to the previous profile if it turns out that their installed package
> manager doesn't support the new profile).

Yeah but... either
1) we use such an obscure profile that noone actually notices the change, or
2) we try to change something in the "big, well-known profiles", 
and then we're back at the start.

So what good is including a feature in a new profile if there is no way to 
make it visible to "the users" in general?

Also, in this particular case, "stable use masking" is useful because it makes 
stabilization possible/simpler in cases where otherwise this would lead to 
broken dependencies (stable depending on ~arch). If only one small sub-profile 
provides the feature, we lose its whole advantage.

-- 
Andreas K. Huettel
Gentoo Linux developer 
kde (team lead), sci, tex, arm, printing
dilfridge@gentoo.org
http://www.akhuettel.de/

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

Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC

[Zac Medico]

On 08/14/2012 03:21 PM, Andreas K. Huettel wrote:
> Am Dienstag, 14. August 2012, 23:55:47 schrieb Zac Medico:
>> It seems like there's some confusion here. Approving a new EAPI and
>> deciding to use a new EAPI in a given profile are two entirely different
>> things. If we want to us a new EAPI in a profile, we just have to deploy
>> it such that users are only exposed to that profile when they
>> consciously running `eselect profile` (and they can always revert back
>> to the previous profile if it turns out that their installed package
>> manager doesn't support the new profile).
> 
> Yeah but... either
> 1) we use such an obscure profile that noone actually notices the change, or
> 2) we try to change something in the "big, well-known profiles", 
> and then we're back at the start.
> 
> So what good is including a feature in a new profile if there is no way to 
> make it visible to "the users" in general?

You do it in all the new profiles, and deprecate the old profiles. Users
see the profile deprecation notice (or news item or other announcement)
and upgrade their profile.

> Also, in this particular case, "stable use masking" is useful because it makes 
> stabilization possible/simpler in cases where otherwise this would lead to 
> broken dependencies (stable depending on ~arch). If only one small sub-profile 
> provides the feature, we lose its whole advantage.

Yeah, that's why I'm saying to do it in *all* new profiles and deprecate
the old ones.
-- 
Thanks,
Zac

Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC

[Michał Górny]

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

On Wed, 15 Aug 2012 13:01:31 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Wed, 15 Aug 2012 00:20:21 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > > There's still the issue that we haven't decided what [use] deps do
> > > when they show up in profile files. We were sticking at 1 until we
> > > worked that out.
> > 
> > Ah, about that. It will be useful if [use] deps in package.mask
> > worked unlike in package.use.mask, thus giving us a tool to
> > temporarily mask packages which are broken only with given flags.
> > 
> > For example, likely it was potentially useful to do something like:
> > 
> >     # something support with intel broken in this version
> >     =media-libs/mesa-N.N.N[someflag,video_cards_intel,!video_cards_radeon,!video_cards_nvidia]
> > 
> > With meaning: mask mesa-N.N.N if 'someflag' and 'video_cards_intel'
> > are enabled, and 'video_cards_radeon' an 'video_cards_nvidia' are
> > disabled.
> > 
> > This will make lives easier both for devs (who wouldn't have to
> > work-around this) and users (for those who will benefit from new
> > mesa, and those who will not upgrade and break their systems).
> 
> The issue there is whether the package mangler should try to solve
> that by tinkering with which flags are selected. The way Paludis
> implements it currently, it would just treat the package as being
> masked and wouldn't try the upgrade; I believe at one point Brian was
> talking about doing something clever with Pkgcore there and using
> that syntax to do use flag masking instead.
> 
> Whichever route we go, there's also the UI question: how do we present
> this to users in a sensible way?

The intent is not to anything clever but just mask the package. Intel
users don't want mesa without support for their card; they simply don't
want the broken version at all.

It should be presented alike regular package.mask, with the whole
atom string.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC

[Ciaran McCreesh]

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

On Wed, 15 Aug 2012 14:11:55 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> > Whichever route we go, there's also the UI question: how do we
> > present this to users in a sensible way?
> 
> The intent is not to anything clever but just mask the package. Intel
> users don't want mesa without support for their card; they simply
> don't want the broken version at all.
> 
> It should be presented alike regular package.mask, with the whole
> atom string.

I'm not sure that it's that simple: what if a user has, say, intel
turned on only because it's on by default in profiles?

-- 
Ciaran McCreesh

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

Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC

[Michał Górny]

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

On Wed, 15 Aug 2012 13:12:17 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Wed, 15 Aug 2012 14:11:55 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > > Whichever route we go, there's also the UI question: how do we
> > > present this to users in a sensible way?
> > 
> > The intent is not to anything clever but just mask the package.
> > Intel users don't want mesa without support for their card; they
> > simply don't want the broken version at all.
> > 
> > It should be presented alike regular package.mask, with the whole
> > atom string.
> 
> I'm not sure that it's that simple: what if a user has, say, intel
> turned on only because it's on by default in profiles?

In this particular case -- nothing, because he has by default other
card settings which make mesa don't trigger the bug. It was simply
a very weird bug which needed a simple solution to avoid spreading it
on users.

-- 
Best regards,
Michał Górny

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

[gentoo-project] Council meeting summary: Tuesday 14 August 2012, 19:00 UTC

[Fabian Groffen]

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

Apologies for sending the summary this late.


Summary of Gentoo council meeting 14th August 2012

Roll call
=========
betelgeuse
chainsaw
grobian
scarabeus
ulm
williamh

absent
------
dberkholz (receives slacker mark)


EAPI5 features
==============
Due to holidays, the list of features for EAPI5 was announced only 2
days in advance of the meeting.  This gave little time for Council
members to prepare for votes.
Therefore a vote was conducted if voting on EAPI5 features in this
meeting was deemed suitable.

The Council voted unanimously to postpone voting on EAPI5 features.

The list of features for EAPI5 were outlined by ulm in
http://thread.gmane.org/gmane.linux.gentoo.project/2101/focus=2115
Since many of these features appear not to be implemented in Portage, a
discussion on their implementation is called for by the Council.  The
Council stressed that it prefers to vote on EAPI5 features that can and
will be implemented within a short timeframe, say 1 month.


Open bugs with Council involvement
==================================
There are currently no open bugs.


Open floor
==========
scarabeus suggested the change "dev should use latest eapi when bumping"
to "dev must use latest eapi when bumping if not forbidden by eclasses".
He was asked to bring it up on the mailing lists, to get a better
definition of when what EAPI should be used.

ulm raised deprecation of EAPI 1 on request of patrick.  Arfrever argued
that backwards compatability is not an issue here, and that it can
greatly reduce code size/maintenance of eclasses when EAPI0 and EAPI1
are removed.  It was questioned whether removal of an EAPI really brings
that much benefits.  It seems eclasses can drop support for EAPIs, if
all consumers don't use them, which does not require complete removal of
the EAPI.  It appears some packages use build-systems that require
EAPI1.


Next meeting date
=================
11 September 2012, 19:00 UTC


-- 
Fabian Groffen
Gentoo on a different level

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

Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC

[David Leverton]

On 14 August 2012 23:20, Michał Górny <mgorny@gentoo.org> wrote:
> On Tue, 14 Aug 2012 23:02:04 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
>> There's still the issue that we haven't decided what [use] deps do
>> when they show up in profile files. We were sticking at 1 until we
>> worked that out.
>
> Ah, about that. It will be useful if [use] deps in package.mask worked
> unlike in package.use.mask, thus giving us a tool to temporarily mask
> packages which are broken only with given flags.

Do we have a verdict on this?  What Michał suggests for package.mask
sounds OK to me, but use deps in package.use, package.use.mask, etc
could be rather nastier, and I'd be inclined to ban those unless
someone has a better idea.

Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC

[Brian Harring]

On Sat, Sep 08, 2012 at 02:12:40PM +0100, David Leverton wrote:
> On 14 August 2012 23:20, Micha?? G??rny <mgorny@gentoo.org> wrote:
> > On Tue, 14 Aug 2012 23:02:04 +0100
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> >> There's still the issue that we haven't decided what [use] deps do
> >> when they show up in profile files. We were sticking at 1 until we
> >> worked that out.
> >
> > Ah, about that. It will be useful if [use] deps in package.mask worked
> > unlike in package.use.mask, thus giving us a tool to temporarily mask
> > packages which are broken only with given flags.
> 
> Do we have a verdict on this?  What Micha?? suggests for package.mask
> sounds OK to me, but use deps in package.use, package.use.mask, etc
> could be rather nastier, and I'd be inclined to ban those unless
> someone has a better idea.

Use deps in all *.mask are already banned; whether by spec or 
convention- when they were added the potential was known, and stated 
as "don't do that".

If we're going to try doing it now, analysis needs to be done to see 
what fallout there is *before trying to change the fucking thing*.

Offhand, I'd strongly bet no PM will handle a use dep atom in 
package.mask now; as for *.use.* abuse of use deps, that's frankly 
worse- it's chained deps, "if this use configuration, mask that flag".  
That's hell on wheels for the PM to implement.

Personally, I'd like to see 'dev-util/diffball[debug]' usable in 
package.use.mask (instead of dev-util/diffball debug), but it's not a 
backwards compatible change w/ existing PMs.

Either way, the verdict is "can't go anywhere till compatibility is 
figured out" :P

~harring