[gentoo-project] Call for agenda items -- Council meeting 09-10-2012

[gentoo-project] Call for agenda items -- Council meeting 09-10-2012

[Fabian Groffen]

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

In two weeks from now, the council will meet again. This is the time to
raise and prepare items that the council should put on the agenda to
discuss or vote on.

Please respond to this email with agenda items. Please do not hestitate
to repeat your agenda item here with a pointer if you previously
suggested one (since the last meeting).

The agenda for the next meeting will be sent out on Tuesday 2th of
October 2012.

Please respond to the gentoo-project list, if possible.

Fabian


-- 
Fabian Groffen
Gentoo on a different level

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

Re: [gentoo-project] Call for agenda items -- Council meeting 09-10-2012

[Ulrich Mueller]

>>>>> On Tue, 25 Sep 2012, Fabian Groffen wrote:

> In two weeks from now, the council will meet again. This is the time
> to raise and prepare items that the council should put on the agenda
> to discuss or vote on.

> Please respond to this email with agenda items. Please do not
> hestitate to repeat your agenda item here with a pointer if you
> previously suggested one (since the last meeting).

I've two items:

- Allow using EAPI 5 in the tree.
  Portage supports EAPI 5 since version 2.1.11.19.

- Package names:
  Our current spec forbids that package names "end in a hyphen
  followed by one or more digits". This isn't consequent, since it
  still allows PN to be e.g. "foo-1a" which looks like a valid PF.
  OTOH, there's no technical reason for this limitation (backwards
  compatibility issues taken aside).
  Since this issue is open since more than five years, I believe that
  it's time to ask the council for guidance in what direction we
  should go:
    a) Drop the limitation entirely (possibly in a future EAPI).
    b) Make it stricter, i.e. disallow package names ending in a
       hyphen followed by anything that looks like a valid PVR.
       This is current Portage behaviour, and the tree complies with
       it, too.
    c) Leave the spec as it is (and make Portage comply with it).
  See bug 174536 for details.

Ulrich

Re: [gentoo-project] Call for agenda items -- Council meeting 09-10-2012

[Ulrich Mueller]

>>>>> On Tue, 25 Sep 2012, Ulrich Mueller wrote:

> - Package names:
>   Our current spec forbids that package names "end in a hyphen
>   followed by one or more digits". This isn't consequent, since it
>   still allows PN to be e.g. "foo-1a" which looks like a valid PF.
>   OTOH, there's no technical reason for this limitation (backwards
>   compatibility issues taken aside).
>   Since this issue is open since more than five years, I believe that
>   it's time to ask the council for guidance in what direction we
>   should go:
>     a) Drop the limitation entirely (possibly in a future EAPI).
>     b) Make it stricter, i.e. disallow package names ending in a
>        hyphen followed by anything that looks like a valid PVR.
>        This is current Portage behaviour, and the tree complies with
>        it, too.
>     c) Leave the spec as it is (and make Portage comply with it).
>   See bug 174536 for details.

Actually, there's also:
    d) Require a) for Package managers and b) by tree policy
       (Postel's Law, brought up by mgorny). Practically, this would
       mean that repoman would reject "foo-1" as package name, but the
       rest of Portage would accept it.

Ulrich

Re: [gentoo-project] Call for agenda items -- Council meeting 09-10-2012

[Brian Harring]

On Thu, Sep 27, 2012 at 08:19:13AM +0200, Ulrich Mueller wrote:
> >>>>> On Tue, 25 Sep 2012, Ulrich Mueller wrote:
> 
> > - Package names:
> >   Our current spec forbids that package names "end in a hyphen
> >   followed by one or more digits". This isn't consequent, since it
> >   still allows PN to be e.g. "foo-1a" which looks like a valid PF.
> >   OTOH, there's no technical reason for this limitation (backwards
> >   compatibility issues taken aside).
> >   Since this issue is open since more than five years, I believe that
> >   it's time to ask the council for guidance in what direction we
> >   should go:
> >     a) Drop the limitation entirely (possibly in a future EAPI).
> >     b) Make it stricter, i.e. disallow package names ending in a
> >        hyphen followed by anything that looks like a valid PVR.
> >        This is current Portage behaviour, and the tree complies with
> >        it, too.
> >     c) Leave the spec as it is (and make Portage comply with it).
> >   See bug 174536 for details.
> 
> Actually, there's also:
>     d) Require a) for Package managers and b) by tree policy
>        (Postel's Law, brought up by mgorny). Practically, this would
>        mean that repoman would reject "foo-1" as package name, but the
>        rest of Portage would accept it.

Grr.  And people wonder why I get brutally blunt at times.

This restriction, whether people like it or not, is encoded into 
some fairly core places that have consequences.  You do this, you 
break all existing managers that see it in the vdb.  Not "oh looky, a 
warning, isn't that cute by mildly annoying", break.

Badly. Break.  PM shats the bed, traceback gets thrown.

Considering managers do full graphs, that node gets touched, the 
affected PM isn't going to be able to even upgrade it's way out of it- 
best case, if it's implemented sanely a --nodeps will avoid that node.  
However a lot of PMs still have legacy virtuals code, meaning if that 
cache is stale, looky looky, the vdb gets walked and you get a 'boom'.

This isn't even commenting on binpkgs, which is where you're likely to 
see older managers existing as clients.

All of that is unversioned.  We cannot hide this sort of change- at 
best we can deploy it, force all QA tools to block it for N years, 
than allow it in; anything else is risking known (yes known, people 
have been pointing this out for ages).

What for?  So someone can name their package foo-1?  Is that really 
such a major gap we're willing to induce breakage?

Will anyone even !@#*ing use a package names foo-1?  I've yet to see 
an example given, just ignoring of the breakage it will induce.

Honestly, you want to push it, you address how this isn't going to 
break things, lay out the timelines, identifying when we willingly 
switchover to breaking managers older than a certain date.  It does 
not get pushed up to the council w/out the negatives/flaws mentioned.

Shorter version; you very clearly left out option C; "leave it as is 
since PMS is filled with warts, this isn't hurting anything, and 
changing it will break things."

~harring

Re: [gentoo-project] Call for agenda items -- Council meeting 09-10-2012

[Ulrich Mueller]

>>>>> On Thu, 27 Sep 2012, Brian Harring wrote:

tl;dr

> Shorter version; you very clearly left out option C; "leave it as is
> since PMS is filled with warts, this isn't hurting anything, and
> changing it will break things."

Problems aren't solved by ignoring them. ;-)

The point is that currently PMS and Portage behaviour disagree.
I think this is not acceptable, otherwise we could as well give up on
the PMS and take the Portage implementation as the reference.

Ulrich

Re: [gentoo-project] Call for agenda items -- Council meeting 09-10-2012

[Brian Harring]

On Fri, Sep 28, 2012 at 02:14:06AM +0200, Ulrich Mueller wrote:
> >>>>> On Thu, 27 Sep 2012, Brian Harring wrote:
> 
> tl;dr
> 
> > Shorter version; you very clearly left out option C; "leave it as is
> > since PMS is filled with warts, this isn't hurting anything, and
> > changing it will break things."
> 
> Problems aren't solved by ignoring them. ;-)

True.  They also multiply if in trying to solve them, you ignore the 
issues of the problem. :P

> The point is that currently PMS and Portage behaviour disagree.
> I think this is not acceptable, otherwise we could as well give up on
> the PMS and take the Portage implementation as the reference.

Yeah, I'm being a bit cracky in biting your head off on this one if 
this is specifically all you're trying to address; discussions I've 
been seeing for this one were to drop the disallowance of -\d$, 
which... per my statements, are borkage inducing; combine that with 
the fact theres been a lot of "lets just ignore borkage" proposals 
lately, and I'm being fairly aggressive/noisy about stopping that.


First thought, that rule was added because portage was buggy
internally... none of us actually needed it except portage.  Portage 
internals now no longer have the underlying flaw that led to it, but 
instead they've gone and cocked it up so the rules are tighter than 
what PMS requires; honestly, I'd be inclined to make portage clean up 
their own mess rather than keep changing the spec for stuff like this- 
largely out of spite/annoyance.  Not exactly great for users however.

Unfortunately, this has been in since at lease cec3c5 (02/10) for 
diffball-1a.  Plus the world isn't that nice I suspect

Currently, the only way such a package would get in is via pkgcore or 
paludis... ie... a PMS compliant manager.  Sucks, but if we're going 
to do anything, we have to tighten the spec, which will be annoying 
for parse speeds (version rules aren't the simplest to apply).

I truly hate having to do that also.

Either way, this angle, have at it, just thought this was another 
"lets drop -\d$ disallowance" proposal, thus the hefty "ah man, not 
this shit again" email.

~harring

Re: [gentoo-project] Call for agenda items -- Council meeting 09-10-2012

[Donnie Berkholz]

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

On 15:13 Thu 27 Sep     , Brian Harring wrote:
> What for?  So someone can name their package foo-1?  Is that really 
> such a major gap we're willing to induce breakage?
> 
> Will anyone even !@#*ing use a package names foo-1?  I've yet to see 
> an example given, just ignoring of the breakage it will induce.

I tend to agree. What value does this provide? It creates additional 
work for no proven real-world benefit.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux <http://dberkholz.com>
Analyst, RedMonk <http://redmonk.com/dberkholz/>

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

Re: [gentoo-project] Call for agenda items -- Council meeting 09-10-2012

[Ulrich Mueller]

>>>>> On Wed, 3 Oct 2012, Donnie Berkholz wrote:

> On 15:13 Thu 27 Sep     , Brian Harring wrote:
>> What for?  So someone can name their package foo-1?  Is that really 
>> such a major gap we're willing to induce breakage?
>> 
>> Will anyone even !@#*ing use a package names foo-1?  I've yet to see 
>> an example given, just ignoring of the breakage it will induce.

> I tend to agree. What value does this provide? It creates additional 
> work for no proven real-world benefit.

As I said before, the point is that the PMS isn't consequent, and
that there is a discrepancy between Portage and the PMS. Portage
is stricter because it also forbids package names like foo-1a or
foo-1_alpha that could be confused with a package name followed by
a version.

(Something along the lines of "a hyphen followed by a digit must not
occur anywhere in a package name" would be even simpler. We cannot
do that because there are packages like font-adobe-100dpi that don't
conform with it.)

Ulrich

Re: [gentoo-project] Call for agenda items -- Council meeting 09-10-2012

[Matt Turner]

On Tue, Oct 2, 2012 at 11:44 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Wed, 3 Oct 2012, Donnie Berkholz wrote:
>
>> On 15:13 Thu 27 Sep     , Brian Harring wrote:
>>> What for?  So someone can name their package foo-1?  Is that really
>>> such a major gap we're willing to induce breakage?
>>>
>>> Will anyone even !@#*ing use a package names foo-1?  I've yet to see
>>> an example given, just ignoring of the breakage it will induce.
>
>> I tend to agree. What value does this provide? It creates additional
>> work for no proven real-world benefit.
>
> As I said before, the point is that the PMS isn't consequent, and
> that there is a discrepancy between Portage and the PMS. Portage
> is stricter because it also forbids package names like foo-1a or
> foo-1_alpha that could be confused with a package name followed by
> a version.
>
> (Something along the lines of "a hyphen followed by a digit must not
> occur anywhere in a package name" would be even simpler. We cannot
> do that because there are packages like font-adobe-100dpi that don't
> conform with it.)
>
> Ulrich
>

This doesn't seem that difficult. How about "$PN must not end in a
hyphen followed by 1 or more digits"?

Re: [gentoo-project] Call for agenda items -- Council meeting 09-10-2012

[Ulrich Mueller]

>>>>> On Tue, 2 Oct 2012, Matt Turner wrote:

> This doesn't seem that difficult. How about "$PN must not end in a
> hyphen followed by 1 or more digits"?

Have you read the rest of this thread? :-(

This is what we have now and Portage doesn't follow it.

Ulrich

Re: [gentoo-project] Call for agenda items -- Council meeting 09-10-2012

[Ciaran McCreesh]

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

On Thu, 27 Sep 2012 08:19:13 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> Actually, there's also:
>     d) Require a) for Package managers and b) by tree policy
>        (Postel's Law, brought up by mgorny). Practically, this would
>        mean that repoman would reject "foo-1" as package name, but the
>        rest of Portage would accept it.

Postel's Law is what lead to the current state of HTML and JavaScript,
where everything has to be tested carefully on dozens of different
browser versions and littered with workarounds. Accepting lax input
just leads to lax input being provided...

-- 
Ciaran McCreesh

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

Re: [gentoo-project] Call for agenda items -- Council meeting 09-10-2012

[Ulrich Mueller]

>>>>> On Sat, 29 Sep 2012, Ciaran McCreesh wrote:

>>     d) Require a) for Package managers and b) by tree policy
>>        (Postel's Law, brought up by mgorny). Practically, this
>>        would mean that repoman would reject "foo-1" as package
>>        name, but the rest of Portage would accept it.

> Postel's Law is what lead to the current state of HTML and
> JavaScript, where everything has to be tested carefully on dozens of
> different browser versions and littered with workarounds. Accepting
> lax input just leads to lax input being provided...

Providing lax input is not at all Postel's Law, but the opposite of it.

In our case, strict input would be enforced with repoman.

Ulrich

Re: [gentoo-project] Call for agenda items -- Council meeting 09-10-2012

[Ciaran McCreesh]

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

On Sat, 29 Sep 2012 18:04:59 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> >>>>> On Sat, 29 Sep 2012, Ciaran McCreesh wrote:
> >>     d) Require a) for Package managers and b) by tree policy
> >>        (Postel's Law, brought up by mgorny). Practically, this
> >>        would mean that repoman would reject "foo-1" as package
> >>        name, but the rest of Portage would accept it.
> 
> > Postel's Law is what lead to the current state of HTML and
> > JavaScript, where everything has to be tested carefully on dozens of
> > different browser versions and littered with workarounds. Accepting
> > lax input just leads to lax input being provided...
> 
> Providing lax input is not at all Postel's Law, but the opposite of
> it.

But as you can see from HTML, and all the stuff Portage accepts
currently, and from countless other examples, the only way to prevent
bad input from being provided is to reject it. Following one half of
Postel's law just leads to the other half being violated.

> In our case, strict input would be enforced with repoman.

Repoman can't parse bash code.

-- 
Ciaran McCreesh

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

Re: [gentoo-project] Call for agenda items -- Council meeting 09-10-2012

[Pacho Ramos]

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

El mar, 25-09-2012 a las 11:24 +0200, Fabian Groffen escribió:
> In two weeks from now, the council will meet again. This is the time to
> raise and prepare items that the council should put on the agenda to
> discuss or vote on.
> 
> Please respond to this email with agenda items. Please do not hestitate
> to repeat your agenda item here with a pointer if you previously
> suggested one (since the last meeting).
> 
> The agenda for the next meeting will be sent out on Tuesday 2th of
> October 2012.
> 
> Please respond to the gentoo-project list, if possible.
> 
> Fabian
> 
> 

This is from:
http://www.gossamer-threads.com/lists/gentoo/dev/260662

But corrected to remember preferred usage of in_iuse from eutils.eclass
as remembered by mgorny in that thread:

--------- Mensaje reenviado --------
De: Pacho Ramos <pacho@gentoo.org>
Reply-to: gentoo-dev@lists.gentoo.org
Para: gentoo-dev@lists.gentoo.org
Asunto: [gentoo-dev] Suggest to specify a way to query for USEs in next
council
Fecha: Sat, 22 Sep 2012 21:41:24 +0200

Hello

This comes from:
http://www.gossamer-threads.com/lists/gentoo/dev/260536

In that one, we try to use the following:
has vala ${IUSE//+/} && ! use vala && return 0 

as already done in many eclasses/ebuilds (some of them as widely used as
xorg-2 or cmake eclasses) for years. The problem is that Ciaran
wants to forbid it because he says it's not specified in PMS and also
the same looks to apply to preferred in_iuse function from eutils.eclass

My suggestion is to simply specify it as it's currently implemented in
portage because that functionality is (apart of needed) being used for a
long time in the tree by numerous eclasses/ebuilds, then, from my point
of view, wouldn't be any sense on lose time for moving them to current
functionality to a worse one, wait for the next eapi and, finally,
revert them back to current behavior. The way it works was kindly
explained to me yesterday by Zac:
http://www.mail-archive.com/gentoo-portage-dev@lists.gentoo.org/msg02830.html

If the behavior need to be changed later in a way it would break the
tree, we could, then, wait for next eapi to change that behavior.

Other option would be to wait for next eapi to specify that, the problem
is that, if that eapi take a long time to be approved, we would need to
move all eclasses/ebuilds to the other non-automatic way to later revert
them back.

And other option could be to include this specification in eapi5 as it's
still not allowed in the tree (maybe for this a council meeting should
be soon enough I guess)

Thanks a lot


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

Re: [gentoo-project] Call for agenda items -- Council meeting 09-10-2012

[Fabian Groffen]

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

Pacho,

On 25-09-2012 21:32:50 +0200, Pacho Ramos wrote:
> This is from:
> http://www.gossamer-threads.com/lists/gentoo/dev/260662
> 
> But corrected to remember preferred usage of in_iuse from eutils.eclass
> as remembered by mgorny in that thread:

I've considered your point, but concluded that at this moment, the
Council basically has nothing to do here.  It seems obvious that it
needs something to be defined in a next EAPI, but the Council is not the
body to invent that.
Please discuss with involved people (Portage devs?) and prepare a patch
to PMS that can be used as feature for the next EAPI.  Brian's
IUSE_FLATTENED might be a simple and good solution for that.

Best,
Fabian

-- 
Fabian Groffen
Gentoo on a different level

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

Re: [gentoo-project] Call for agenda items -- Council meeting 09-10-2012

[Pacho Ramos]

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

El mar, 02-10-2012 a las 13:30 +0200, Fabian Groffen escribió:
> Pacho,
> 
> On 25-09-2012 21:32:50 +0200, Pacho Ramos wrote:
> > This is from:
> > http://www.gossamer-threads.com/lists/gentoo/dev/260662
> > 
> > But corrected to remember preferred usage of in_iuse from eutils.eclass
> > as remembered by mgorny in that thread:
> 
> I've considered your point, but concluded that at this moment, the
> Council basically has nothing to do here.  It seems obvious that it
> needs something to be defined in a next EAPI, but the Council is not the
> body to invent that.
> Please discuss with involved people (Portage devs?) and prepare a patch
> to PMS that can be used as feature for the next EAPI.  Brian's
> IUSE_FLATTENED might be a simple and good solution for that.
> 
> Best,
> Fabian
> 

And what about current usage in the tree with current eapis? Regarding
IUSE_FLATTENED I have no problem with it, but will need to talk with
portage team also as they have the current implementation

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

Re: [gentoo-project] Call for agenda items -- Council meeting 09-10-2012

[Pacho Ramos]

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

El mié, 03-10-2012 a las 19:18 +0200, Pacho Ramos escribió:
> El mar, 02-10-2012 a las 13:30 +0200, Fabian Groffen escribió:
> > Pacho,
> > 
> > On 25-09-2012 21:32:50 +0200, Pacho Ramos wrote:
> > > This is from:
> > > http://www.gossamer-threads.com/lists/gentoo/dev/260662
> > > 
> > > But corrected to remember preferred usage of in_iuse from eutils.eclass
> > > as remembered by mgorny in that thread:
> > 
> > I've considered your point, but concluded that at this moment, the
> > Council basically has nothing to do here.  It seems obvious that it
> > needs something to be defined in a next EAPI, but the Council is not the
> > body to invent that.
> > Please discuss with involved people (Portage devs?) and prepare a patch
> > to PMS that can be used as feature for the next EAPI.  Brian's
> > IUSE_FLATTENED might be a simple and good solution for that.
> > 
> > Best,
> > Fabian
> > 
> 
> And what about current usage in the tree with current eapis? Regarding
> IUSE_FLATTENED I have no problem with it, but will need to talk with
> portage team also as they have the current implementation

And then, I think council should clarify what to do with current usages
in the tree with eapi0-4

Thanks

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

Re: [gentoo-project] Call for agenda items -- Council meeting 09-10-2012

[Fabian Groffen]

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

On 04-10-2012 20:32:41 +0200, Pacho Ramos wrote:
> > And what about current usage in the tree with current eapis? Regarding
> > IUSE_FLATTENED I have no problem with it, but will need to talk with
> > portage team also as they have the current implementation
> 
> And then, I think council should clarify what to do with current usages
> in the tree with eapi0-4

Why should the Council clarify that?

(Not that we're unwilling, but I don't see why Council should be the
initiator here.)


-- 
Fabian Groffen
Gentoo on a different level

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

Re: [gentoo-project] Call for agenda items -- Council meeting 09-10-2012

[Pacho Ramos]

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

El vie, 05-10-2012 a las 08:28 +0200, Fabian Groffen escribió:
> On 04-10-2012 20:32:41 +0200, Pacho Ramos wrote:
> > > And what about current usage in the tree with current eapis? Regarding
> > > IUSE_FLATTENED I have no problem with it, but will need to talk with
> > > portage team also as they have the current implementation
> > 
> > And then, I think council should clarify what to do with current usages
> > in the tree with eapi0-4
> 
> Why should the Council clarify that?
> 

Who should be then? This has been already talked in gentoo-dev and we
still don't know what to do with current ebuild/eclasses already relying
on them, and reverting them to some other solution would later need us
to re-migrate them to current one when it's specified in next EAPI. This
is all explained in original message I send, the problem is that there
is a total lack of knowledge about how to proceed and what to do and,
then, I think that Council should decide it.

> (Not that we're unwilling, but I don't see why Council should be the
> initiator here.)
> 
> 



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

Re: [gentoo-project] Call for agenda items -- Council meeting 09-10-2012

[Patrick Lauer]

On 10/05/12 14:28, Fabian Groffen wrote:
> On 04-10-2012 20:32:41 +0200, Pacho Ramos wrote:
>>> And what about current usage in the tree with current eapis? Regarding
>>> IUSE_FLATTENED I have no problem with it, but will need to talk with
>>> portage team also as they have the current implementation
>>
>> And then, I think council should clarify what to do with current usages
>> in the tree with eapi0-4
> 
> Why should the Council clarify that?
> 
> (Not that we're unwilling, but I don't see why Council should be the
> initiator here.)
> 

For quite a while we have had ideas and discussions about deprecating
older EAPIs - expected benefits being things like not remembering the
little variations between the six official flavours.

I would suggest adding a repoman warning for adding new ebuilds with
EAPI={1,2,3} now, turn that into an error for EAPI 1 in a short time (3
months?), then do the same for EAPI 2 a short while later with a longer
timeline (as there are substantially more ebuilds with EAPI 2)

Re: [gentoo-project] Call for agenda items -- Council meeting 09-10-2012

[Ulrich Mueller]

>>>>> On Fri, 05 Oct 2012, Patrick Lauer wrote:

> I would suggest adding a repoman warning for adding new ebuilds with
> EAPI={1,2,3} now, turn that into an error for EAPI 1 in a short time
> (3 months?), then do the same for EAPI 2 a short while later with a
> longer timeline (as there are substantially more ebuilds with EAPI 2)

I don't see any advantage in deprecating intermediate EAPIs, before we
deprecate EAPI 0. What problem are you trying to solve?

Ulrich

Re: [gentoo-project] Call for agenda items -- Council meeting 09-10-2012

[Rich Freeman]

On Fri, Oct 5, 2012 at 4:46 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
>
> I don't see any advantage in deprecating intermediate EAPIs, before we
> deprecate EAPI 0. What problem are you trying to solve?
>

++

I'm all for a policy that says to use slot deps whenever appropriate,
or to otherwise do things that actually have a real impact on the
quality/functionality of the distro.  That might in practice mean
using newer EAPIs on a lot of stuff.  However, I don't see the value
in bumping for its own sake.

Legislate outcomes, not details.

Rich

Re: [gentoo-project] Call for agenda items -- Council meeting 09-10-2012

[Jeff Horelick]

On 5 October 2012 06:31, Rich Freeman <rich0@gentoo.org> wrote:
> On Fri, Oct 5, 2012 at 4:46 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>
>> I don't see any advantage in deprecating intermediate EAPIs, before we
>> deprecate EAPI 0. What problem are you trying to solve?
>>
>
> ++
>
> I'm all for a policy that says to use slot deps whenever appropriate,
> or to otherwise do things that actually have a real impact on the
> quality/functionality of the distro.  That might in practice mean
> using newer EAPIs on a lot of stuff.  However, I don't see the value
> in bumping for its own sake.
>
> Legislate outcomes, not details.
>
> Rich
>

I don't think deprecating EAPIs for new ebuilds is a good/useful
thing. Sure the new EAPIs are nice and all, but if the package works
fine with an older EAPI and there's no need to use the features of a
newer one, why not leave it?

In some cases, EAPI bumps are detrimental to users on old systems that
have a older portage because they wind up being blocked by stuff like
new portage requiring new python which requires pkgconfig and all
pkgconfig ebuilds are EAPI=4 so you're stuck.

Re: [gentoo-project] Call for agenda items -- Council meeting 09-10-2012

[Pacho Ramos]

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

El vie, 05-10-2012 a las 06:31 -0400, Rich Freeman escribió:
> On Fri, Oct 5, 2012 at 4:46 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
> >
> > I don't see any advantage in deprecating intermediate EAPIs, before we
> > deprecate EAPI 0. What problem are you trying to solve?
> >
> 
> ++
> 
> I'm all for a policy that says to use slot deps whenever appropriate,
> or to otherwise do things that actually have a real impact on the
> quality/functionality of the distro.  That might in practice mean
> using newer EAPIs on a lot of stuff.  However, I don't see the value
> in bumping for its own sake.
> 
> Legislate outcomes, not details.
> 
> Rich
> 
> 

Probably deprecating eapi1 would be interesting as probably most ebuilds
would benefit from having additional src_prepare and src_configure
phases.

Regarding eapi4, it also has interesting changes like automatically
passing --disable-dependency-tracking, they also ban dosed and dohard


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