[gentoo-project] Re: Council Meeting Scheduled for 17 Jun 2014 at 19:00 UTC

[gentoo-project] Re: Council Meeting Scheduled for 17 Jun 2014 at 19:00 UTC

[Ulrich Mueller]

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

>>>>> On Thu, 12 Jun 2014, Rich Freeman wrote:

> The EAPI6 discussion could not be completed in a single meeting
> (surprise!) so we will be continuing next week on 17 Jun 2014 at
> 19:00 UTC.

> The agenda is unchanged and there is no call for more items:
> http://dev.gentoo.org/~rich0/council/council_agenda_20140610.txt

For the case that we accept 4b "User patches" and 4a "Patch applying
function in package manager", I wonder if we shouldn't re-take the
vote on 1d "PATCHES support in default src_prepare" (which was a tie).

IMHO, once the PM has a patch function, leaving PATCHES out won't make
much sense.

Ulrich

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

Re: [gentoo-project] Re: Council Meeting Scheduled for 17 Jun 2014 at 19:00 UTC

[Michał Górny]

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

Dnia 2014-06-13, o godz. 11:50:37
Ulrich Mueller <ulm@gentoo.org> napisał(a):

> For the case that we accept 4b "User patches" and 4a "Patch applying
> function in package manager", I wonder if we shouldn't re-take the
> vote on 1d "PATCHES support in default src_prepare" (which was a tie).
> 
> IMHO, once the PM has a patch function, leaving PATCHES out won't make
> much sense.

Yes, especially if the Council decides to apply user patches by
default. Then the following default would make sense:

src_prepare() {
  [[ ${PATCHES[@]} ]] && eapply "${PATCHES[@]}"
  eapply_user
}

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Re: Council Meeting Scheduled for 17 Jun 2014 at 19:00 UTC

[Ulrich Mueller]

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

>>>>> On Fri, 13 Jun 2014, Michał Górny wrote:

>   [[ ${PATCHES[@]} ]] && eapply "${PATCHES[@]}"

Since it is meant as replacement for base.eclass functionality, we
should also support PATCHES as a whitespace separated list.

As an added bonus, that would be consistent with how we handle the
DOCS variable.

Ulrich

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

Re: [gentoo-project] Re: Council Meeting Scheduled for 17 Jun 2014 at 19:00 UTC

[Rich Freeman]

On Fri, Jun 13, 2014 at 5:50 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
>
> For the case that we accept 4b "User patches" and 4a "Patch applying
> function in package manager", I wonder if we shouldn't re-take the
> vote on 1d "PATCHES support in default src_prepare" (which was a tie).

Makes sense.

I think the real objection isn't to those particular EAPI features,
but rather a philosophical debate over what belongs in EAPI vs what
belongs in eclasses.  I already put in my two cents on -dev on that
one.

Rich