[gentoo-project] Call for agenda items - Council meeting 2013-04-09

[gentoo-project] Call for agenda items - Council meeting 2013-04-09

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 483 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 hesitate
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
2nd of April 2013.

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

Ulrich

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

Re: [gentoo-project] Call for agenda items - Council meeting 2013-04-09

[Michał Górny]

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

On Tue, 26 Mar 2013 18:14:07 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

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

I would like the Council to take an initial look, and possible vote on
switching to a newer bash version (preferably bash-4.2, stable Sep
2012) in the next EAPI (bug #431340 [1]).

This would need some kind of schedule since it depends on EAPI parsing
which went stable in Jul 2012). If the transition period needs to be
extended, I'd prefer having it in EAPI 6 anyway but adding a policy
like 'do not use it in global scope until ...', so that pre-EAPI-6
package manager compatibility would be retained.

[1]:https://bugs.gentoo.org/show_bug.cgi?id=431340

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Call for agenda items - Council meeting 2013-04-09

[Ulrich Mueller]

>>>>> On Sat, 30 Mar 2013, Michał Górny wrote:

> I would like the Council to take an initial look, and possible vote
> on switching to a newer bash version (preferably bash-4.2, stable
> Sep 2012) in the next EAPI (bug #431340 [1]).

AFAICS, bash-4.2_p20 went stable in March 2012 already. [2]

> This would need some kind of schedule since it depends on EAPI
> parsing which went stable in Jul 2012). If the transition period
> needs to be extended, I'd prefer having it in EAPI 6 anyway but
> adding a policy like 'do not use it in global scope until ...', so
> that pre-EAPI-6 package manager compatibility would be retained.

This could be done of course. But extrapolating from previous EAPIs,
I think that we can't expect EAPI 6 to be ready before July anyway.

Ulrich

> [1]:https://bugs.gentoo.org/show_bug.cgi?id=431340

[2] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-shells/bash/bash-4.2_p20.ebuild?hideattic=0&revision=1.11&view=markup

[gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Ulrich Mueller]

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

One agenda item I'd like to add myself is EAPI deprecation (again).
We're collecting items for EAPI 6 already, and with this being
deployed there would be seven EAPIs in use.

http://qa-reports.gentoo.org/output/eapi_usage.txt says:

   repository '/usr/portage':
     eapi: '4' 12928 pkgs found, 39.10% of the repository
     eapi: '0' 7041 pkgs found, 21.29% of the repository
     eapi: 'unsupported' 4630 pkgs found, 14.00% of the repository
     eapi: '2' 4289 pkgs found, 12.97% of the repository
     eapi: '3' 3748 pkgs found, 11.34% of the repository
     eapi: '1' 429 pkgs found, 1.30% of the repository

   Date generated: Tue Apr  2 13:03:17 UTC 2013

We already "encourage" using the newest EAPI, see 20110308 meeting.
(Though I fail to find this recommendation in the devmanual, shouldn't
it be there?)

Should we have a stricter rule? Would such a rule help significantly
reducing the number of EAPI 0 ebuilds?

Ulrich

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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Rich Freeman]

On Tue, Apr 2, 2013 at 10:25 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
> We already "encourage" using the newest EAPI, see 20110308 meeting.
> (Though I fail to find this recommendation in the devmanual, shouldn't
> it be there?)
>
> Should we have a stricter rule? Would such a rule help significantly
> reducing the number of EAPI 0 ebuilds?

Anticipating the likely objection (which I'm sure the Council is
already well aware of), perhaps a more constructive way to look at
this is whether there is a way to better promote adoption of slot
operators wherever it is applicable?  That would be something that
would create real tangible improvement to the distro that most devs
would really get behind (IMHO).

I'm fine with even turning that into a quality rule - deps should
support subslots where appropriate, and packages should use slot
operators where appropriate.  Obviously there is a transition
involved.

Rich

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Markos Chandras]

On 2 April 2013 15:25, Ulrich Mueller <ulm@gentoo.org> wrote:
>      eapi: 'unsupported' 4630 pkgs found, 14.00% of the repository

What does the 'unsupported' stand for? What EAPI is this?

> We already "encourage" using the newest EAPI, see 20110308 meeting.
> (Though I fail to find this recommendation in the devmanual, shouldn't
> it be there?)

Probably yes but I need a bug about this otherwise I will forget about
it (or better yet someone can fix it for me)

>
> Should we have a stricter rule? Would such a rule help significantly
> reducing the number of EAPI 0 ebuilds?
I believe so. Maybe make repoman scream if you commit an ebuild with
1<=EAPI<=4 ?

--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Michał Górny]

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

On Tue, 2 Apr 2013 16:31:51 +0100
Markos Chandras <hwoarang@gentoo.org> wrote:

> On 2 April 2013 15:25, Ulrich Mueller <ulm@gentoo.org> wrote:
> >      eapi: 'unsupported' 4630 pkgs found, 14.00% of the repository
> 
> What does the 'unsupported' stand for? What EAPI is this?

EAPI=5. It's not supported by pkgcore yet.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Ralph Sennhauser]

On Tue, 2 Apr 2013 16:31:51 +0100
Markos Chandras <hwoarang@gentoo.org> wrote:

> > Should we have a stricter rule? Would such a rule help significantly
> > reducing the number of EAPI 0 ebuilds?  
> I believe so. Maybe make repoman scream if you commit an ebuild with
> 1<=EAPI<=4 ?

I feel strongly against starting with anything but EAPI 0. And I
don't consider EAPI 4 old enough to start pestering maintainers about
it.

What we need is a live cycle of EAPIs to keep things manageable in the
long run. We aren't under pressure to get rid of as many as possible
ASAP. A simple scheme could be

- EAPI becomes second latest
- 5 years later repoman warns.
- 2 years later repoman errors out.

With that scheme EAPI=0  would be due soon. As the "bump to latest
eapi" policy isn't that old and seems to have only sunk in a about a
year ago, and the myth of still requiring system packages to be EAPI=0
kept a lot of the tree at EAPI=0 for a long time. Fact is EAPI 0 ebuilds
are still many, though the number started to crumble significantly
lately. So waiting another year before starting actively warn might be
appropriate.

The important thing is for the council to declare intent and timeframe,
so maintainers can plan far ahead. The other thing that became apparent
from last discussion is that a slightly low EAPI shouldn't be a card
blanch for zealots to touch packages they don't maintain or to file
bugs about it.

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[vivo75]

Il 03/04/2013 11:07, Ralph Sennhauser ha scritto:
> On Tue, 2 Apr 2013 16:31:51 +0100
> Markos Chandras <hwoarang@gentoo.org> wrote:
>
>>> Should we have a stricter rule? Would such a rule help significantly
>>> reducing the number of EAPI 0 ebuilds?  
>> I believe so. Maybe make repoman scream if you commit an ebuild with
>> 1<=EAPI<=4 ?
> I feel strongly against starting with anything but EAPI 0. And I
> don't consider EAPI 4 old enough to start pestering maintainers about
> it.
>
> What we need is a live cycle of EAPIs to keep things manageable in the
> long run. We aren't under pressure to get rid of as many as possible
> ASAP. A simple scheme could be
>
> - EAPI becomes second latest
> - 5 years later repoman warns.
> - 2 years later repoman errors out.
>
> With that scheme EAPI=0  would be due soon. As the "bump to latest
> eapi" policy isn't that old and seems to have only sunk in a about a
> year ago, and the myth of still requiring system packages to be EAPI=0
> kept a lot of the tree at EAPI=0 for a long time. Fact is EAPI 0 ebuilds
> are still many, though the number started to crumble significantly
> lately. So waiting another year before starting actively warn might be
> appropriate.
>
> The important thing is for the council to declare intent and timeframe,
> so maintainers can plan far ahead. The other thing that became apparent
> from last discussion is that a slightly low EAPI shouldn't be a card
> blanch for zealots to touch packages they don't maintain or to file
> bugs about it.
>

Hopefully the council will keep in mind that today it's not possible to
upgrade portage if the system is old enough to require an update from
python-2.6.5-r2 => :2.7, at least not with a lot of trickery with
--nodeps and (much more) equally ugly stuff. python-2.6.5-r2 is dated 01
May 2010 in ChangeLog.

3 years are pratically more than you can ever hope to support without
adding manpower dedicated to keep backward compatibility.

Previous reasoning based on the assumption that a) newer api are better
b) less of them is better c) not being able to upgrade portage mean a
not upgradable/modifiable gentoo install.

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Zac Medico]

On 04/03/2013 02:31 AM, vivo75@gmail.com wrote:
> 3 years are pratically more than you can ever hope to support without
> adding manpower dedicated to keep backward compatibility.
> 
> Previous reasoning based on the assumption that a) newer api are better
> b) less of them is better c) not being able to upgrade portage mean a
> not upgradable/modifiable gentoo install.

It's a little bit silly to try to maintain backward compatibility for
more than 3 years when you can easily revive an old system by bind
mounting it into a fresh chroot as suggested here:

 https://bugs.gentoo.org/show_bug.cgi?id=457148
-- 
Thanks,
Zac

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[vivo75]

Il 03/04/2013 17:22, Zac Medico ha scritto:
> On 04/03/2013 02:31 AM, vivo75@gmail.com wrote:
>> 3 years are pratically more than you can ever hope to support without
>> adding manpower dedicated to keep backward compatibility.
>>
>> Previous reasoning based on the assumption that a) newer api are better
>> b) less of them is better c) not being able to upgrade portage mean a
>> not upgradable/modifiable gentoo install.
> It's a little bit silly to try to maintain backward compatibility for
> more than 3 years when you can easily revive an old system by bind
> mounting it into a fresh chroot as suggested here:
>
>  https://bugs.gentoo.org/show_bug.cgi?id=457148
indeed that look a very good solution, this would also keep Gentoo
rolling and avoid support EAPI=0 for the next X years (or at least
having a deprecation time much shorter than 5 years)? Hopefully so.

New ebuilds should be written using newer EAPI waiting for the shrinking
number of old ones to being ported by some superhuman in his free time.

[gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Ulrich Mueller]

>>>>> On Wed, 3 Apr 2013, Ralph Sennhauser wrote:

> I feel strongly against starting with anything but EAPI 0. And I
> don't consider EAPI 4 old enough to start pestering maintainers
> about it.

> What we need is a live cycle of EAPIs to keep things manageable in
> the long run. We aren't under pressure to get rid of as many as
> possible ASAP. A simple scheme could be

> - EAPI becomes second latest
> - 5 years later repoman warns.
> - 2 years later repoman errors out.

To start with some numbers, here are the Portage versions
corresponding to EAPIs, together with their stabilisation dates:

   EAPI   approved     Portage version   stable on all arches
   (0)                 2.0.53 (*)        2005-12-26
   1                   2.1.3.19          2007-12-11
   2      2008-09-25   2.1.6.4           2009-01-08
   3      2010-01-18   2.1.7.17          2010-03-08
   4      2011-01-17   2.1.9.42          2011-03-17
   5      2012-09-20   2.1.11.31         2012-12-11

   (*) First EAPI aware Portage version

An EAPI becomes second latest when the following EAPI becomes stable
on all architectures. For example, EAPI 3 went stable at 2010-03-08
and EAPI 2 became second latest at the same day.

I agree with Francesco and Zac though, that support for 5 or even 7
year old systems isn't realistic at all. IMHO, we should go for an
intermediate time frame like 3 years (maybe 4, if we want to be very
conservative) for EAPI deprecation. This would limit the number of
EAPIs in active use to not more than four or five.

> With that scheme EAPI=0 would be due soon. As the "bump to latest
> eapi" policy isn't that old and seems to have only sunk in a about a
> year ago, and the myth of still requiring system packages to be
> EAPI=0 kept a lot of the tree at EAPI=0 for a long time. Fact is
> EAPI 0 ebuilds are still many, though the number started to crumble
> significantly lately. So waiting another year before starting
> actively warn might be appropriate.

I'd be a little more proactive and deprecate EAPIs 0 and 1 immediately
(which would correspond to the 4 years mentioned above). When doing a
version or revision bump, the ebuild should be updated to use a newer
EAPI. There can be exceptions, e.g. for security bumps.

> The important thing is for the council to declare intent and
> timeframe, so maintainers can plan far ahead. The other thing that
> became apparent from last discussion is that a slightly low EAPI
> shouldn't be a card blanch for zealots to touch packages they don't
> maintain or to file bugs about it.

Right, there's nothing wrong with existing ebuilds using EAPI 3 or 4,
unless you need a newer feature like subslots.

Ulrich

[gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Ryan Hill]

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

On Fri, 5 Apr 2013 18:54:50 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> I'd be a little more proactive and deprecate EAPIs 0 and 1 immediately
> (which would correspond to the 4 years mentioned above). When doing a
> version or revision bump, the ebuild should be updated to use a newer
> EAPI. There can be exceptions, e.g. for security bumps.

Toolchain packages are EAPI 0 and we aren't changing.


-- 
gcc-porting
toolchain, wxwidgets                                     by design, by neglect
@ gentoo.org                                     for a fact or just for effect

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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Pacho Ramos]

El sáb, 06-04-2013 a las 15:43 -0600, Ryan Hill escribió:
> On Fri, 5 Apr 2013 18:54:50 +0200
> Ulrich Mueller <ulm@gentoo.org> wrote:
> 
> > I'd be a little more proactive and deprecate EAPIs 0 and 1 immediately
> > (which would correspond to the 4 years mentioned above). When doing a
> > version or revision bump, the ebuild should be updated to use a newer
> > EAPI. There can be exceptions, e.g. for security bumps.
> 
> Toolchain packages are EAPI 0 and we aren't changing.
> 

and why? Only for knowing the reasons :)

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Andreas K. Huettel]

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

Am Samstag, 6. April 2013, 23:43:14 schrieb Ryan Hill:
> On Fri, 5 Apr 2013 18:54:50 +0200
> 
> Ulrich Mueller <ulm@gentoo.org> wrote:
> > I'd be a little more proactive and deprecate EAPIs 0 and 1 immediately
> > (which would correspond to the 4 years mentioned above). When doing a
> > version or revision bump, the ebuild should be updated to use a newer
> > EAPI. There can be exceptions, e.g. for security bumps.
> 
> Toolchain packages are EAPI 0 and we aren't changing.

That sounds a bit like "over my ..."
Care to elaborate why?


-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


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

[gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Ryan Hill]

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

On Sun, 7 Apr 2013 00:37:22 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:

> Am Samstag, 6. April 2013, 23:43:14 schrieb Ryan Hill:
> > On Fri, 5 Apr 2013 18:54:50 +0200
> > 
> > Ulrich Mueller <ulm@gentoo.org> wrote:
> > > I'd be a little more proactive and deprecate EAPIs 0 and 1 immediately
> > > (which would correspond to the 4 years mentioned above). When doing a
> > > version or revision bump, the ebuild should be updated to use a newer
> > > EAPI. There can be exceptions, e.g. for security bumps.
> > 
> > Toolchain packages are EAPI 0 and we aren't changing.
> 
> That sounds a bit like "over my ..."
> Care to elaborate why?

Every time this comes up we explain why.  Please refer to those threads for the
complete story.

In short:
Toolchain packages, for better or worse, are built by eclass.  We are not
forward-porting toolchain.eclass every time someone decides there are too many
EAPIs in the tree.  Every change to that eclass breaks something (the trick is
to break things people don't care about any more and hope no one notices).  I
don't know the ins and outs of glibc's eblits but I doubt they would be simple
to port either.  I also don't know much about toolchain-binutils.eclass, but
it seems like it would be doable.

Other packages are already on later EAPIs.

There is no reason to remove EAPI 0.  Leave it as the baseline that other
EAPI's are defined by.  Most devs will not be dealing with these packages, so
it really doesn't affect them.  Since there is no reason to remove it, we will
continue to use it.


-- 
gcc-porting
toolchain, wxwidgets                                     by design, by neglect
@ gentoo.org                                     for a fact or just for effect

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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Ciaran McCreesh]

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

On Sat, 6 Apr 2013 20:05:11 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:
> In short:
> Toolchain packages, for better or worse, are built by eclass.  We are
> not forward-porting toolchain.eclass every time someone decides there
> are too many EAPIs in the tree.  Every change to that eclass breaks
> something (the trick is to break things people don't care about any
> more and hope no one notices).  I don't know the ins and outs of
> glibc's eblits but I doubt they would be simple to port either.  I
> also don't know much about toolchain-binutils.eclass, but it seems
> like it would be doable.

Sounds like a good opportunity to replace toolchain.eclass with
something clean and understandable.

-- 
Ciaran McCreesh

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

[gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Ryan Hill]

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

On Sun, 7 Apr 2013 08:27:18 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Sat, 6 Apr 2013 20:05:11 -0600
> Ryan Hill <dirtyepic@gentoo.org> wrote:
> > In short:
> > Toolchain packages, for better or worse, are built by eclass.  We are
> > not forward-porting toolchain.eclass every time someone decides there
> > are too many EAPIs in the tree.  Every change to that eclass breaks
> > something (the trick is to break things people don't care about any
> > more and hope no one notices).  I don't know the ins and outs of
> > glibc's eblits but I doubt they would be simple to port either.  I
> > also don't know much about toolchain-binutils.eclass, but it seems
> > like it would be doable.
> 
> Sounds like a good opportunity to replace toolchain.eclass with
> something clean and understandable.

Sure, I suppose if we were trying to break everything all at once that would
be the most efficient way to go about it.


-- 
gcc-porting
toolchain, wxwidgets                                     by design, by neglect
@ gentoo.org                                     for a fact or just for effect

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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Tom Wijsman]

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

On Sun, 7 Apr 2013 03:34:05 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:

> On Sun, 7 Apr 2013 08:27:18 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> 
> Sure, I suppose if we were trying to break everything all at once
> that would be the most efficient way to go about it.

What's stopping you? An overlay is perfect for this.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Rich Freeman]

On Sun, Apr 7, 2013 at 10:00 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Sun, 7 Apr 2013 03:34:05 -0600
> Ryan Hill <dirtyepic@gentoo.org> wrote:
>
>> On Sun, 7 Apr 2013 08:27:18 +0100
>> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
>>
>> Sure, I suppose if we were trying to break everything all at once
>> that would be the most efficient way to go about it.
>
> What's stopping you? An overlay is perfect for this.

I imagine they could ask you the exact same thing.  Again, this is a
volunteer project.

If you don't like how something works, volunteer!

I'll let the toolchain maintainers speak for themselves though.  From
what I'm reading here it sounds like we should be happy to have a
toolchain at all.  If people want them to do more than they're already
doing somebody will have to step up and help them do it.

Simply writing a policy and getting the council to approve it won't
make the work happen.  I'm working on a policy for copyright
attribution/assignment/etc and one of my biggest concerns is how easy
it will be to comply with.  If it isn't easy, then either it won't be
obeyed, or work that could otherwise get done won't get done because
everybody is spending all their time checking copyright notices.  I'd
even prefer a suboptimal policy that gets followed to a "perfect" one
that gets ignored.

Rich

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Ciaran McCreesh]

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

On Sun, 7 Apr 2013 10:46:29 -0400
Rich Freeman <rich0@gentoo.org> wrote:
> I'll let the toolchain maintainers speak for themselves though.  From
> what I'm reading here it sounds like we should be happy to have a
> toolchain at all.  If people want them to do more than they're already
> doing somebody will have to step up and help them do it.

A large part of this is self-inflicted. Toolchain packages contain all
sorts of "cunning plan" tricks that rely upon implementation flukes,
unspecified behaviour, etc. Eblits are the prime example, but there are
plenty more too... Unfortunately the toolchain maintainers don't appear
to be prepared to fix these mistakes.

-- 
Ciaran McCreesh

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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Tom Wijsman]

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

On Sun, 7 Apr 2013 10:46:29 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Sun, Apr 7, 2013 at 10:00 AM, Tom Wijsman <TomWij@gentoo.org>
> wrote:
>
> I imagine they could ask you the exact same thing.  Again, this is a
> volunteer project.
> 
> If you don't like how something works, volunteer!
> 
> I'll let the toolchain maintainers speak for themselves though.  From
> what I'm reading here it sounds like we should be happy to have a
> toolchain at all.  If people want them to do more than they're already
> doing somebody will have to step up and help them do it.
> 
> Simply writing a policy and getting the council to approve it won't
> make the work happen. ...

Yeah, doesn't have to be you. So we should rather look out for more
people; maybe I'll try to have a stab at it at some later point, after
I've revised everything I've committed. "Not enough manpower" is a
valid reason to hold back removal, everything that wonders why EAPI
0 is still around will agree with that...

"... we should be happy to have a toolchain ..." confirms that; so,
who's up for trying to accomplish an EAPI 5 or 6 eclass in an overlay?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Markos Chandras]

On 7 April 2013 08:27, Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> On Sat, 6 Apr 2013 20:05:11 -0600
> Ryan Hill <dirtyepic@gentoo.org> wrote:
>> In short:
>> Toolchain packages, for better or worse, are built by eclass.  We are
>> not forward-porting toolchain.eclass every time someone decides there
>> are too many EAPIs in the tree.  Every change to that eclass breaks
>> something (the trick is to break things people don't care about any
>> more and hope no one notices).  I don't know the ins and outs of
>> glibc's eblits but I doubt they would be simple to port either.  I
>> also don't know much about toolchain-binutils.eclass, but it seems
>> like it would be doable.
>
> Sounds like a good opportunity to replace toolchain.eclass with
> something clean and understandable.
>
> --
> Ciaran McCreesh

I see no reason to break something that works just fine as it is.

--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Ben de Groot]

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

On 7 April 2013 18:13, Markos Chandras <hwoarang@gentoo.org> wrote:

> On 7 April 2013 08:27, Ciaran McCreesh <ciaran.mccreesh@googlemail.com>
> wrote:
> > On Sat, 6 Apr 2013 20:05:11 -0600
> > Ryan Hill <dirtyepic@gentoo.org> wrote:
> >> In short:
> >> Toolchain packages, for better or worse, are built by eclass.  We are
> >> not forward-porting toolchain.eclass every time someone decides there
> >> are too many EAPIs in the tree.  Every change to that eclass breaks
> >> something (the trick is to break things people don't care about any
> >> more and hope no one notices).  I don't know the ins and outs of
> >> glibc's eblits but I doubt they would be simple to port either.  I
> >> also don't know much about toolchain-binutils.eclass, but it seems
> >> like it would be doable.
> >
> > Sounds like a good opportunity to replace toolchain.eclass with
> > something clean and understandable.
> >
> > --
> > Ciaran McCreesh
>
> I see no reason to break something that works just fine as it is.
>
>
Except it doesn't work just fine if it is so fragile as to break at the
smallest change (e.g. EAPI bump)...

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

[-- Attachment #2: Type: text/html, Size: 1916 bytes --]

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Markos Chandras]

On 7 April 2013 11:41, Ben de Groot <yngwin@gentoo.org> wrote:
> On 7 April 2013 18:13, Markos Chandras <hwoarang@gentoo.org> wrote:
>>
>> On 7 April 2013 08:27, Ciaran McCreesh <ciaran.mccreesh@googlemail.com>
>> wrote:
>> > On Sat, 6 Apr 2013 20:05:11 -0600
>> > Ryan Hill <dirtyepic@gentoo.org> wrote:
>> >> In short:
>> >> Toolchain packages, for better or worse, are built by eclass.  We are
>> >> not forward-porting toolchain.eclass every time someone decides there
>> >> are too many EAPIs in the tree.  Every change to that eclass breaks
>> >> something (the trick is to break things people don't care about any
>> >> more and hope no one notices).  I don't know the ins and outs of
>> >> glibc's eblits but I doubt they would be simple to port either.  I
>> >> also don't know much about toolchain-binutils.eclass, but it seems
>> >> like it would be doable.
>> >
>> > Sounds like a good opportunity to replace toolchain.eclass with
>> > something clean and understandable.
>> >
>> > --
>> > Ciaran McCreesh
>>
>> I see no reason to break something that works just fine as it is.
>>
>
> Except it doesn't work just fine if it is so fragile as to break at the
> smallest change (e.g. EAPI bump)...
>

Errr so you are just repeating what I said? It works fine as it is, it
breaks with other EAPIs so just leave it as it is.

--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Tom Wijsman]

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

On Sun, 7 Apr 2013 11:51:30 +0100
Markos Chandras <hwoarang@gentoo.org> wrote:

> On 7 April 2013 11:41, Ben de Groot <yngwin@gentoo.org> wrote:
>
> Errr so you are just repeating what I said? It works fine as it is, it
> breaks with other EAPIs so just leave it as it is.

Why should we wait until it becomes utterly broken? Why should it stop
improvement of the rest of the environment? Do you really want to keep
unmodifiable legacy software that appears to work to you but is broken
by design? It is always better to look at a future-proof solution now
instead of applying even more hacks in the future...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Michał Górny]

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

On Sun, 7 Apr 2013 11:13:10 +0100
Markos Chandras <hwoarang@gentoo.org> wrote:

> On 7 April 2013 08:27, Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > On Sat, 6 Apr 2013 20:05:11 -0600
> > Ryan Hill <dirtyepic@gentoo.org> wrote:
> >> In short:
> >> Toolchain packages, for better or worse, are built by eclass.  We are
> >> not forward-porting toolchain.eclass every time someone decides there
> >> are too many EAPIs in the tree.  Every change to that eclass breaks
> >> something (the trick is to break things people don't care about any
> >> more and hope no one notices).  I don't know the ins and outs of
> >> glibc's eblits but I doubt they would be simple to port either.  I
> >> also don't know much about toolchain-binutils.eclass, but it seems
> >> like it would be doable.
> >
> > Sounds like a good opportunity to replace toolchain.eclass with
> > something clean and understandable.
> 
> I see no reason to break something that works just fine as it is.

I'm afraid this is quite short-sighted.

Well, I have to believe that it works since I don't even try to get
nearby those ebuilds. Those are simply impossible to understand without
detailed study of all involved files, and those are huge.

The problem is that we can't assume it will work forever, and we can't
assume that if it stops working, there will be somebody around who
knows what is going on in there.

I see that the key components of Gentoo system are complex, fragile
and understood only by the few people who maintain them *now*. That
doesn't sound like a bright future to me.

-- 
Best regards,
Michał Górny

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

[gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Michael Palimaka]

On 7/04/2013 20:13, Markos Chandras wrote:
> I see no reason to break something that works just fine as it is.

That is a fallacy. There are good reasons not to bump EAPI of toolchain 
packages in-place, the above is not one of them.

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Andreas K. Huettel]

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

Am Sonntag, 7. April 2013, 04:05:11 schrieb Ryan Hill:
> Toolchain packages, for better or worse, are built by eclass.  We are not
> forward-porting toolchain.eclass every time someone decides there are too
> many EAPIs in the tree.  Every change to that eclass breaks something (the
> trick is to break things people don't care about any more and hope no one
> notices).  I don't know the ins and outs of glibc's eblits but I doubt
> they would be simple to port either.  I also don't know much about
> toolchain-binutils.eclass, but it seems like it would be doable.
> 

So who are the people who do know the ins and outs?
http://en.wikipedia.org/wiki/Bus_factor

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Andreas K. Huettel]

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

Am Sonntag, 7. April 2013, 04:05:11 schrieb Ryan Hill:
> Toolchain packages, for better or worse, are built by eclass.  We are not
> forward-porting toolchain.eclass every time someone decides there are too
> many EAPIs in the tree.  Every change to that eclass breaks something (the
> trick is to break things people don't care about any more and hope no one
> notices). 

I'm sorry, but this comes over roughly like follows:

"We're the only ones doing really complex stuff in the tree, you know, 
eclasses! Can't really be bothered to clean up the code, especially not for 
such pointless things as improvements in package manager handling. Our code is 
highly complex and really fragile, so every small change breaks things. We're 
trying to hide this as well as we can, thank you for not noticing."

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Rich Freeman]

On Sun, Apr 7, 2013 at 8:08 AM, Andreas K. Huettel <dilfridge@gentoo.org> wrote:
> Am Sonntag, 7. April 2013, 04:05:11 schrieb Ryan Hill:
>> Toolchain packages, for better or worse, are built by eclass.  We are not
>> forward-porting toolchain.eclass every time someone decides there are too
>> many EAPIs in the tree.  Every change to that eclass breaks something (the
>> trick is to break things people don't care about any more and hope no one
>> notices).
>
> I'm sorry, but this comes over roughly like follows:
>
> "We're the only ones doing really complex stuff in the tree, you know,
> eclasses! Can't really be bothered to clean up the code, especially not for
> such pointless things as improvements in package manager handling. Our code is
> highly complex and really fragile, so every small change breaks things. We're
> trying to hide this as well as we can, thank you for not noticing."

Well, they are volunteers.

If somebody wants to clean up the eclasses nobody can stop them from
doing so.  Just do it in an overlay and once it is working and tested
it can be moved over.

Is the toolchain being EAPI0 actually hurting anything?  If it is,
then that should be motivation for those being hurt to step up and
help fix the parts that are hurting them.

Personally I'd rather see the toolchain be EAPI0 than maintainer-needed.

Rich

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Andreas K. Huettel]

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

Am Sonntag, 7. April 2013, 14:24:32 schrieb Rich Freeman:
> On Sun, Apr 7, 2013 at 8:08 AM, Andreas K. Huettel <dilfridge@gentoo.org> 
wrote:
> 
> Personally I'd rather see the toolchain be EAPI0 than maintainer-needed.

Oh I certainly agree with you there. 

>
> Is the toolchain being EAPI0 actually hurting anything?  If it is,
> then that should be motivation for those being hurt to step up and
> help fix the parts that are hurting them.

There are a few points (but they have all already been presented to death 
here). Most important are in my personal opinion the longer-term implications.

1) The bitrot corner.
We're already discouraging the use of old EAPIs for new ebuilds. This 
requirement will likely become more stringent at some point. Totally 
independent of that, however, because of nice new features, the number of 
newer EAPI ebuilds is growing a lot. At some point, EAPI=0 will become the 
least-tested codepath in the package managers.

2) Recruitment.
"Here, sonny, let me show you our list of EAPI versions. Make sure you 
memorize these by heart and dont confuse them. We try to improve them every 
now and then, but since people insist on using the old ones anyway, well, we 
have to keep them around. Have fun." 
That problem, of course, could also be solved (and will eventually be solved 
that way if needed) by telling new recruits "Unless you want to contribute to 
obscure stuff like toolchain, you don't have to care about the deprecated 
EAPIs. 4 and up is fine." Bus factor anyone?

Finally, let me remark that the new EAPIs did not drop from a tree during a 
thunderstorm. Ideas were introduced for a reason, they were discussed here, 
the features were selected, and eventually the whole package was decided by 
the council. 

A large-scale project like Gentoo lives from the cooperation of everyone 
involved. This is why I tend to react harsh to declarations by fiat like 
"Toolchain packages are EAPI 0 and we aren't changing.". Especially if they 
involve a team at the core of the whole distribution.

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Rich Freeman]

On Sun, Apr 7, 2013 at 9:37 AM, Andreas K. Huettel <dilfridge@gentoo.org> wrote:
> 2) Recruitment.
> "Here, sonny, let me show you our list of EAPI versions. Make sure you
> memorize these by heart and dont confuse them. We try to improve them every
> now and then, but since people insist on using the old ones anyway, well, we
> have to keep them around. Have fun."
> That problem, of course, could also be solved (and will eventually be solved
> that way if needed) by telling new recruits "Unless you want to contribute to
> obscure stuff like toolchain, you don't have to care about the deprecated
> EAPIs. 4 and up is fine." Bus factor anyone?

We don't teach existing developers the new EAPIs, so why would we
teach new developers the old EAPIs?

That's what documentation is for - the purpose of recruiting isn't to
teach documentation regurgitation.  The main purpose of recruiting is
to screen out people who lack maturity/care/etc.

A developer with commit access that doesn't understand EAPI2 doesn't
concern me much.  A developer with commit access that understands all
the EAPIs perfectly and loves to do tree-wide scripted commits without
notice or formal testing every other Tuesday concerns me a great deal,
even if they haven't broken anything yet.

The problem isn't ignorance, but innocence.  We're all ignorant at
some level, but some at least understand this and act accordingly.

Rich

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Tom Wijsman]

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

On Sun, 7 Apr 2013 09:43:29 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Sun, Apr 7, 2013 at 9:37 AM, Andreas K. Huettel
> <dilfridge@gentoo.org> wrote:
>
> We don't teach existing developers the new EAPIs, so why would we
> teach new developers the old EAPIs?

Markos reviewed my knowledge of the old EAPIs and expected I knew them.
 
> That's what documentation is for - the purpose of recruiting isn't to
> teach documentation regurgitation.  The main purpose of recruiting is
> to screen out people who lack maturity/care/etc.

Everybody has to start somewhere. I wasn't careful lately which has
resulted in my first last rite and learning better about proper package
testing; ironically, the problem here is mostly a lack of documentation.

> A developer with commit access that doesn't understand EAPI2 doesn't
> concern me much.

It gets fun when he starts changing the ebuild, as a result he wouldn't
understand how to 1) adjust it in EAPI2 or 2) port it to EAPI5.

> A developer with commit access that understands all
> the EAPIs perfectly and loves to do tree-wide scripted commits without
> notice or formal testing every other Tuesday concerns me a great deal,
> even if they haven't broken anything yet.

Yeah, there appears to be no documentation and rules for that in place;
this happened a few times lately, nothing bad seems to have happened.
These are long time developers, which makes me more concerned...

> The problem isn't ignorance, but innocence.  We're all ignorant at
> some level, but some at least understand this and act accordingly.

It's rather about the right amount of communication and the right
amount of silence, I wouldn't call either side good.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Ciaran McCreesh]

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

On Sun, 7 Apr 2013 08:24:32 -0400
Rich Freeman <rich0@gentoo.org> wrote:
> Is the toolchain being EAPI0 actually hurting anything?

eblits certainly are. They're a horrific hack that should never have
been allowed in the tree.

-- 
Ciaran McCreesh

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

[gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Ryan Hill]

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

On Sun, 7 Apr 2013 14:08:57 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:

> Am Sonntag, 7. April 2013, 04:05:11 schrieb Ryan Hill:
> > Toolchain packages, for better or worse, are built by eclass.  We are not
> > forward-porting toolchain.eclass every time someone decides there are too
> > many EAPIs in the tree.  Every change to that eclass breaks something (the
> > trick is to break things people don't care about any more and hope no one
> > notices). 
> 
> I'm sorry, but this comes over roughly like follows:
> 
> "We're the only ones doing really complex stuff in the tree, you know, 
> eclasses! Can't really be bothered to clean up the code, especially not for 
> such pointless things as improvements in package manager handling. Our code
> is highly complex and really fragile, so every small change breaks things.
> We're trying to hide this as well as we can, thank you for not noticing."

Hrm.  I just meant that package eclasses suck. I hate the fact that they
effectively make stable moot.  There is no such thing as a stable keyword for a
package built by an eclass.  It's like working without a net.  When it's a core
system package it's twice as bad.

As far as these eclasses go, toolchain is the worst.  Yes, it is fragile
and complex.  It's over a decade's worth of spaghetti code.  It builds 12 years
of gcc releases.  It's hairy.  Everything depends on everything else, and
everything is based on assumptions and implications that may or may not still
be relevant.  Making "obviously" correct changes has often broken something
somewhere else, time and again.  I'm not telling you this for some kind of
perverse bragging rights.  It's not something to be proud of.  I just want you
to understand how easy it is to fuck things up.

When it breaks, it breaks stable.  I absolutely hate breaking stable.  I lose
sleep over it.

So I'm sorry if I come across as "we can't be bothered", but I'm not changing
things if they don't absolutely need to be changed. There are two of us. Mike
takes care of half the tree.  I have maybe an hour or two for Gentoo a night
and I spend all that time fixing already existing bugs.  I would absolutely
love to overhaul the eclass - I think I would learn a hell of a lot doing it -
but I don't have the time to deal with the fallout and frankly I'm not that
irresponsible that I would put people through that just for my own amusement.

If someone else wants to try and improve the situation, please feel free.

So unless you're lobbying for the actual removal of EAPI 0, which I don't think
you are, I don't think we'll be changing at this time.


-- 
gcc-porting
toolchain, wxwidgets                                     by design, by neglect
@ gentoo.org                                     for a fact or just for effect

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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Michał Górny]

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

On Mon, 8 Apr 2013 23:20:28 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:

> If someone else wants to try and improve the situation, please feel free.

Just to be sure -- would you be ok if we tried to inline some
of the eclass code into the ebuilds (future versions/revbumps)?

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Rich Freeman]

On Tue, Apr 9, 2013 at 1:57 AM, Michał Górny <mgorny@gentoo.org> wrote:
> On Mon, 8 Apr 2013 23:20:28 -0600
> Ryan Hill <dirtyepic@gentoo.org> wrote:
>
>> If someone else wants to try and improve the situation, please feel free.
>
> Just to be sure -- would you be ok if we tried to inline some
> of the eclass code into the ebuilds (future versions/revbumps)?

Honestly, when you're talking about small numbers of packages I think
this is the only thing which is sustainable.

Eclasses should perform generic functions which have well-defined
inputs and outputs which are broadly applicable.  When you start
building them for small groups of packages you start to run into
situations like this.

If your ebuilds basically just contain KEYWORDS and little more then
the eclasses are doing too much for sure.

I can see the need for cases like python/perl/etc eclasses when you
have a large number of packages which need similar logic, but if the
inputs/outputs of the functions change then the functions should
change names.  So, rather than overriding src_prepare and then doing a
bunch of logic to figure out which of 12 different upstream packaging
approaches was in use it should just have 12 different functions and
the ebuild should call the right one from its own src_prepare.  Then
you can actually deprecate functions that are no longer needed, and
not change functions that are being used in stable (or if you change
them you're less likely to break them because each function only
operates on a well-defined set of inputs and outputs).

Bottom line is that automagic eclasses can sometimes be as bad as
automagic build systems, for most of the same reasons.

And that isn't even getting into the fact that we don't really have
any mechanism for getting rid of eclasses.  All that crufty code just
collects.

(I'm sure I missed a few good uses for eclasses above, but I'd still
tend to say that if an eclass function is accepting data in many
different formats it is probably doing too much.)

Rich

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Mike Frysinger]

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

On Tuesday 09 April 2013 01:57:47 Michał Górny wrote:
> On Mon, 8 Apr 2013 23:20:28 -0600 Ryan Hill wrote:
> > If someone else wants to try and improve the situation, please feel free.
> 
> Just to be sure -- would you be ok if we tried to inline some
> of the eclass code into the ebuilds (future versions/revbumps)?

not really.  you can still build gcc-2.95 and newer with the current code, but 
the amount of "tc_version_is_at_least" is fairly low.  from time to time, 
people also create their own gcc ebuild forks which use this eclass either 
because it's a completely different code base, orit has some serious patches 
that we aren't interested in carrying, or people want to experiment.  current 
examples: kgcc64 msp430 gcc-apple.  we've had other embedded works in the 
past, as well as hardened ones.
-mike

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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Michał Górny]

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

On Tue, 9 Apr 2013 15:24:10 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> On Tuesday 09 April 2013 01:57:47 Michał Górny wrote:
> > On Mon, 8 Apr 2013 23:20:28 -0600 Ryan Hill wrote:
> > > If someone else wants to try and improve the situation, please feel free.
> > 
> > Just to be sure -- would you be ok if we tried to inline some
> > of the eclass code into the ebuilds (future versions/revbumps)?
> 
> not really.  you can still build gcc-2.95 and newer with the current code, but 
> the amount of "tc_version_is_at_least" is fairly low.  from time to time, 
> people also create their own gcc ebuild forks which use this eclass either 
> because it's a completely different code base, orit has some serious patches 
> that we aren't interested in carrying, or people want to experiment.  current 
> examples: kgcc64 msp430 gcc-apple.  we've had other embedded works in the 
> past, as well as hardened ones.

Then please don't create a fake feeling like you're going to accept
help to improve the situation.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Mike Frysinger]

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

On Tuesday 09 April 2013 16:24:16 Michał Górny wrote:
> On Tue, 9 Apr 2013 15:24:10 -0400 Mike Frysinger wrote:
> > On Tuesday 09 April 2013 01:57:47 Michał Górny wrote:
> > > On Mon, 8 Apr 2013 23:20:28 -0600 Ryan Hill wrote:
> > > > If someone else wants to try and improve the situation, please feel
> > > > free.
> > > 
> > > Just to be sure -- would you be ok if we tried to inline some
> > > of the eclass code into the ebuilds (future versions/revbumps)?
> > 
> > not really.  you can still build gcc-2.95 and newer with the current
> > code, but the amount of "tc_version_is_at_least" is fairly low.  from
> > time to time, people also create their own gcc ebuild forks which use
> > this eclass either because it's a completely different code base, orit
> > has some serious patches that we aren't interested in carrying, or
> > people want to experiment.  current examples: kgcc64 msp430 gcc-apple. 
> > we've had other embedded works in the past, as well as hardened ones.
> 
> Then please don't create a fake feeling like you're going to accept
> help to improve the situation.

i have no idea wtf you're talking about
-mike

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

[gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Ryan Hill]

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

On Tue, 9 Apr 2013 22:24:16 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Tue, 9 Apr 2013 15:24:10 -0400
> Mike Frysinger <vapier@gentoo.org> wrote:
> 
> > On Tuesday 09 April 2013 01:57:47 Michał Górny wrote:
> > > On Mon, 8 Apr 2013 23:20:28 -0600 Ryan Hill wrote:
> > > > If someone else wants to try and improve the situation, please feel
> > > > free.
> > > 
> > > Just to be sure -- would you be ok if we tried to inline some
> > > of the eclass code into the ebuilds (future versions/revbumps)?
> > 
> > not really.  you can still build gcc-2.95 and newer with the current code,
> > but the amount of "tc_version_is_at_least" is fairly low.  from time to
> > time, people also create their own gcc ebuild forks which use this eclass
> > either because it's a completely different code base, orit has some serious
> > patches that we aren't interested in carrying, or people want to
> > experiment.  current examples: kgcc64 msp430 gcc-apple.  we've had other
> > embedded works in the past, as well as hardened ones.
> 
> Then please don't create a fake feeling like you're going to accept
> help to improve the situation.

These are things the eclass has to support and the restraints we have to work
under.  Don't throw a snit if you don't like the problem space.


-- 
gcc-porting
toolchain, wxwidgets                                     by design, by neglect
@ gentoo.org                                     for a fact or just for effect

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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Michał Górny]

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

On Tue, 9 Apr 2013 18:07:28 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:

> On Tue, 9 Apr 2013 22:24:16 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > On Tue, 9 Apr 2013 15:24:10 -0400
> > Mike Frysinger <vapier@gentoo.org> wrote:
> > 
> > > On Tuesday 09 April 2013 01:57:47 Michał Górny wrote:
> > > > On Mon, 8 Apr 2013 23:20:28 -0600 Ryan Hill wrote:
> > > > > If someone else wants to try and improve the situation, please feel
> > > > > free.
> > > > 
> > > > Just to be sure -- would you be ok if we tried to inline some
> > > > of the eclass code into the ebuilds (future versions/revbumps)?
> > > 
> > > not really.  you can still build gcc-2.95 and newer with the current code,
> > > but the amount of "tc_version_is_at_least" is fairly low.  from time to
> > > time, people also create their own gcc ebuild forks which use this eclass
> > > either because it's a completely different code base, orit has some serious
> > > patches that we aren't interested in carrying, or people want to
> > > experiment.  current examples: kgcc64 msp430 gcc-apple.  we've had other
> > > embedded works in the past, as well as hardened ones.
> > 
> > Then please don't create a fake feeling like you're going to accept
> > help to improve the situation.
> 
> These are things the eclass has to support and the restraints we have to work
> under.  Don't throw a snit if you don't like the problem space.

My point is that if you'll put everything into the eclass you're never
going to improve it. It will be just going from one mess into another,
and the ebuilds should never go stable if they don't even have their
own phase functions.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[vivo75]

On 04/10/13 05:41, Michał Górny wrote:
> On Tue, 9 Apr 2013 18:07:28 -0600
> Ryan Hill <dirtyepic@gentoo.org> wrote:
>
>> On Tue, 9 Apr 2013 22:24:16 +0200
>> Michał Górny <mgorny@gentoo.org> wrote:
>>
>>> On Tue, 9 Apr 2013 15:24:10 -0400
>>> Mike Frysinger <vapier@gentoo.org> wrote:
>>>
>>>> On Tuesday 09 April 2013 01:57:47 Michał Górny wrote:
>>>>> On Mon, 8 Apr 2013 23:20:28 -0600 Ryan Hill wrote:
>>>>>> If someone else wants to try and improve the situation, please feel
>>>>>> free.
>>>>> Just to be sure -- would you be ok if we tried to inline some
>>>>> of the eclass code into the ebuilds (future versions/revbumps)?
>>>> not really.  you can still build gcc-2.95 and newer with the current code,
>>>> but the amount of "tc_version_is_at_least" is fairly low.  from time to
>>>> time, people also create their own gcc ebuild forks which use this eclass
>>>> either because it's a completely different code base, orit has some serious
>>>> patches that we aren't interested in carrying, or people want to
>>>> experiment.  current examples: kgcc64 msp430 gcc-apple.  we've had other
>>>> embedded works in the past, as well as hardened ones.
>>> Then please don't create a fake feeling like you're going to accept
>>> help to improve the situation.
>> These are things the eclass has to support and the restraints we have to work
>> under.  Don't throw a snit if you don't like the problem space.
> My point is that if you'll put everything into the eclass you're never
> going to improve it. It will be just going from one mess into another,
> and the ebuilds should never go stable if they don't even have their
> own phase functions.
>
Actually putting everithing in an eclass could make maintenaince easyer
and faster while providing history of changes.
My example being mysql (and forks) which use mysql*.eclass.
Stability for the mysql packages has been good, while maintaining
_multiple_ versions of them actually useable.

Disclaimer:
The actual mantainers opinion may be even the opposite of this one, and
mine may very well be biased, since I'm the one who moved the ebuild in
the eclasses few years ago.

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Tom Wijsman]

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

On Wed, 10 Apr 2013 15:02:44 +0200
"vivo75@gmail.com" <vivo75@gmail.com> wrote:

> Actually putting everithing in an eclass could make maintenaince
> easyer and faster while providing history of changes.

That's not necessarily true, this entirely depends on how the eclass is
implemented and what you are putting into it. This also takes into
account not having one eclass to rule em all or an eclass that covers
just two lines, there's a right amount to it; in this case, the eclass
just doesn't work out the way you'd want to. It breaks because of that.

> My example being mysql (and forks) which use mysql*.eclass.
> Stability for the mysql packages has been good, while maintaining
> _multiple_ versions of them actually useable.
>
> Disclaimer:
> The actual mantainers opinion may be even the opposite of this one,
> and mine may very well be biased, since I'm the one who moved the
> ebuild in the eclasses few years ago.

Some eclasses being usable doesn't mean that all eclasses are usable.
This thread isn't about moving code to an eclass, it's rather about the
eclass itself being poorly designed and the ways people want to deal
(or not deal) with it; this in itself is a sub discussion of whether to
plan to get rid of EAPI 0 next council meeting.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Donnie Berkholz]

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

On 23:20 Mon 08 Apr     , Ryan Hill wrote:
> Hrm.  I just meant that package eclasses suck. I hate the fact that they
> effectively make stable moot.  There is no such thing as a stable keyword for a
> package built by an eclass.  It's like working without a net.  When it's a core
> system package it's twice as bad.
> 
> As far as these eclasses go, toolchain is the worst.  Yes, it is fragile
> and complex.  It's over a decade's worth of spaghetti code.  It builds 12 years
> of gcc releases.  It's hairy.  Everything depends on everything else, and
> everything is based on assumptions and implications that may or may not still
> be relevant.  Making "obviously" correct changes has often broken something
> somewhere else, time and again.  I'm not telling you this for some kind of
> perverse bragging rights.  It's not something to be proud of.  I just want you
> to understand how easy it is to fuck things up.
> 
> When it breaks, it breaks stable.  I absolutely hate breaking stable.  I lose
> sleep over it.

You could probably deal with this through much more aggressive bumping 
of eclass versions in concert with ebuild bumps, followed by eclass 
freezes once their users go stable.

-- 
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] Re: Call for agenda items - Council meeting 2013-04-09

[hasufell]

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

On 04/09/2013 08:12 PM, Donnie Berkholz wrote:
> On 23:20 Mon 08 Apr     , Ryan Hill wrote:
>> Hrm.  I just meant that package eclasses suck. I hate the fact
>> that they effectively make stable moot.  There is no such thing
>> as a stable keyword for a package built by an eclass.  It's like
>> working without a net.  When it's a core system package it's
>> twice as bad.
>> 
>> As far as these eclasses go, toolchain is the worst.  Yes, it is
>> fragile and complex.  It's over a decade's worth of spaghetti
>> code.  It builds 12 years of gcc releases.  It's hairy.
>> Everything depends on everything else, and everything is based on
>> assumptions and implications that may or may not still be
>> relevant.  Making "obviously" correct changes has often broken
>> something somewhere else, time and again.  I'm not telling you
>> this for some kind of perverse bragging rights.  It's not
>> something to be proud of.  I just want you to understand how easy
>> it is to fuck things up.
>> 
>> When it breaks, it breaks stable.  I absolutely hate breaking
>> stable.  I lose sleep over it.
> 
> You could probably deal with this through much more aggressive
> bumping of eclass versions in concert with ebuild bumps, followed
> by eclass freezes once their users go stable.
> 

That makes it even worse IMO and introduces more confusion and
complexity when writing/dealing with ebuilds. I am more thinking of
something similar to autoconf.
Once an ebuild goes stable it will be generated as a static ebuild
based on the current state of the eclasses. That will introduce a few
problems (such as how to handle global eclass scope), but I think they
are solvable.
Imo we could even ignore PMS here, since we would basically just dump
all related eclass functions into the ebuild and drop the eclass inherit.
We could write a tool to do and revert that and make it more readable etc.

But this is just a thought, maybe I am wrong and it's even more
complicated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRZVj4AAoJEFpvPKfnPDWzmb8H/03CUA/EYM5ZIiAGY9KqZZ9L
/3wRtCG5ywfi7COq0xA08YK60Bj1pHiGgSaJvIu0e9SsVc/Vqv3g0Z0EBpUUA1DR
3m8cqu7HpaG0N7MZ03jrRzzjo3bGmmkuvT2jG7d1YTUekfz1kpoUpe790F2Ps9IE
fABT56pCZnE+Cnpa6G+pEbC7BBzSFsZC1A4XRRWiHaveWECDzC+ovexP08UV4BjS
Pie5Od0oZNYUQtQyWE86ypS6Zd+LfguByblHkLj25s+1OgGvzkSc46pR3J5RKLFs
gypJOe0IMWyn4/+YqGF+fQyPLBf4bhtUmzl+wF3ObkTUSF7uSU1n3ibvsH2BTAA=
=bykX
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Tom Wijsman]

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

On Wed, 10 Apr 2013 14:20:08 +0200
hasufell <hasufell@gentoo.org> wrote:

> Once an ebuild goes stable it will be generated as a static ebuild
> based on the current state of the eclasses.

That's what Portage does, it creates an environment file.

> That will introduce a few problems (such as how to handle global
> eclass scope), but I think they are solvable.

Portage has solved these problems, no need to solve hem again.

Eclasses aren't meant to be used like this, there will surely be some
trouble when going through with this; why take this meta approach if you
could rewrite the eclass itself instead and make it conform?

> Imo we could even ignore PMS here, since we would basically just dump
> all related eclass functions into the ebuild and drop the eclass
> inherit. We could write a tool to do and revert that and make it more
> readable etc.

I don't think that this is the way we should cope with legacy code.

This makes the situation even worse; this would ignore a specification,
re-implement something we already have in Portage and lead to code that
can't and shouldn't be re-used. I think time is better spent on making
it work with Portage than to waste time reinventing parts of Portage.

- -- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQEcBAEBAgAGBQJRZWJyAAoJEJWyH81tNOV9i9MIAIU8/YBoP3kch5geAqjeIhti
TaKpOxlAgxT5j0FCn7pjOYo+HGzoL7eWwvDqcBZ9H0z5qPjC8I2Xc4JenLLPjsV2
leKvkSsoQEBy30wgGU4WjYOvq2XyubTAp7ZgEk3MKaw4pvX93RwXGBBJYzeJ9fOO
pgtw0IQZef+pNWvxilwi9ObTvRMmyQQB4XG1O/UEi76UKwQKUH0SJG9ksodxUA7C
s6JCG8MUZp+IG57AbpxP9p3i6tTi4T7KWdZiu69WfFZe5f1tMWZxc9ZvZwqEbws6
/4cUhphirnxYWtab2jDwf/JYuOBRhC3RPBZvDr8m2VUb8QZIGoms0kGK29n1ypI=
=Tiu9
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[hasufell]

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

On 04/10/2013 03:00 PM, Tom Wijsman wrote:
> On Wed, 10 Apr 2013 14:20:08 +0200 hasufell <hasufell@gentoo.org>
> wrote:
> 
>> That will introduce a few problems (such as how to handle global 
>> eclass scope), but I think they are solvable.
> 
> Portage has solved these problems, no need to solve hem again.

It has not, because it's not a problem on PM level.

> 
> Eclasses aren't meant to be used like this, there will surely be
> some trouble when going through with this; why take this meta
> approach if you could rewrite the eclass itself instead and make it
> conform?

To ensure that code _behind_ a stable ebuild does not change. EAPI
versions already try to solve this and that's why we have EAPI
confusion. Now we want to add eclass confusion by introducing versions
for them too?

It's like you would "statically link" the eclasses if that makes it
more clear what I am talking about.

> 
>> Imo we could even ignore PMS here, since we would basically just
>> dump all related eclass functions into the ebuild and drop the
>> eclass inherit. We could write a tool to do and revert that and
>> make it more readable etc.
> 
> I don't think that this is the way we should cope with legacy
> code.
> 
> This makes the situation even worse; this would ignore a
> specification, re-implement something we already have in Portage
> and lead to code that can't and shouldn't be re-used. I think time
> is better spent on making it work with Portage than to waste time
> reinventing parts of Portage.
> 

It does not ignore specification. It complies with specification. The
problem is if it can be implemented sanely.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRZWZKAAoJEFpvPKfnPDWzMoUIAJWTudQ1/3UmZtJhvkttsgb5
GZS34RIU86VjntSpDgmkPGwkRcCxPoV2IjOuWq8l4+mhFo3imlI9pcpPiKyZpNZD
j8Fw/fJjiDs2+Qc7OeND64TZzGzTiFYGhzNnEN5AbDrUhvBUf9Mnyk1/EB6AXRhX
uTDYIQIO5PyZ9fY+N9aTX0GxfgKQZdh06j3t350hgwBDyGJCl/96Nl+UBRLBFrQ6
g9s5Hp7cYxvQ/lvi7zIfuZzqWgS5j6eqxL3gF0qDiqVk9PcOLZaoxlNg9IqWtAWk
ZyAHmrLa3RQiLLSsojAg5TrtmQKmDvaOvaKwpiMe+AsViDFYIFOhSnvFRl8Oglc=
=vWvj
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Tom Wijsman]

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

On Wed, 10 Apr 2013 15:16:58 +0200
hasufell <hasufell@gentoo.org> wrote:

> It has not, because it's not a problem on PM level.

So that environment file is magic that comes from nowhere?

> To ensure that code _behind_ a stable ebuild does not change.

Eclasses that do not evolve, that's a new thing. They'll have to
eventually evolve anyway, or are we putting a halt to innovation?

> EAPI versions already try to solve this and that's why we have EAPI
> confusion.

What exactly is EAPI confusion? If everyone just uses the latest one and
stop holding on to EAPI 0 you wouldn't have any kind of confusion, this
is what deprecation of the older EAPIs is all about.

> Now we want to add eclass confusion by introducing versions for them
> too?

Eclasses eventually end up being legacy code because the needs and
usage of them changes over time; so, yes, we will want to write new
versions of them and avoid confusion by dropping the older ones. You
see the same happen with programming libraries and other fields...

> It's like you would "statically link" the eclasses if that makes it
> more clear what I am talking about.

Ugh, that sounds like http://sta.li/

Statically linking is all shiny, but how does it solve the problem?

> It does not ignore specification. It complies with specification. The
> problem is if it can be implemented sanely.

How is your "ignore PMS" suggestion complying with the PMS? It is not.

The problem is not the implementation, but whether to re-implement it.
We're talking about one eclass and some packages here, not the tree;
therefore it be a waste of effort time to write this tool, better spend
on actually dealing with the problem this thread tries to address.

It ignores PMS, it ignores the fact it is legacy code, it ignores that
it blocks deprecation of the EAPI, it breaks easily; the list goes on.

- -- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQEcBAEBAgAGBQJRZWvpAAoJEJWyH81tNOV9/F0H/inIjulzWmv607Rb/Pu0sz6u
SOtNd6IW9C6vmArZcYxPxa8MzfN2sUSHiFjd9EQsgwZrpHe5hxBTHyxqgqM2syHv
PIbKeJAFWfJyv/74dF+le0u9KpwgJJtnDaqE56I6YQ+x0R66MHyFXDlf6FMZTTAc
pbsTssw3wkhjvhqaW2iqMIFW0I+OiUd15AmX0Ajg09IWdXdhI+EIpA3/5v+5OA1S
mvDODLrzvRqN9vUPGKvOnvhrS3EaFpR6g13noDSKM4Z8046BtoXlFI9SwJKXqilT
m0FZR6K2g2QbzJGh6uZW38mDtSpaRGNK/ebMFRnxhx/hKfIMu6iXbQMiVmot4WY=
=XwQf
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[hasufell]

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

On 04/10/2013 03:40 PM, Tom Wijsman wrote:
> On Wed, 10 Apr 2013 15:16:58 +0200 hasufell <hasufell@gentoo.org>
> wrote:
> 
>> It has not, because it's not a problem on PM level.
> 
> So that environment file is magic that comes from nowhere?

That environment file saves the whole environment including user
settings. How does that fit the idea I just posted here? It does not.

Parts of the code could probably be used, but again: this is not a PM
problem.

> 
>> To ensure that code _behind_ a stable ebuild does not change.
> 
> Eclasses that do not evolve, that's a new thing. They'll have to 
> eventually evolve anyway, or are we putting a halt to innovation?

What? You seem to misunderstand what I am saying. I am talking about
something similar to autoconf which generates a configure file
depending on the present state of macros/m4 files etc.

This does not halt eclass development in any way and would only apply
to _stable_ ebuilds.

> 
>> EAPI versions already try to solve this and that's why we have
>> EAPI confusion.
> 
> What exactly is EAPI confusion? If everyone just uses the latest
> one and stop holding on to EAPI 0 you wouldn't have any kind of
> confusion, this is what deprecation of the older EAPIs is all
> about.

EAPI confusion is the amount of EAPIs a new developer has to know in
order to understand ebuilds. I am not arguing egainst EAPIs here. This
is just about eclasses.

> 
>> Now we want to add eclass confusion by introducing versions for
>> them too?
> 
> Eclasses eventually end up being legacy code because the needs and 
> usage of them changes over time; so, yes, we will want to write
> new versions of them and avoid confusion by dropping the older
> ones. You see the same happen with programming libraries and other
> fields...
> 
>> It's like you would "statically link" the eclasses if that makes
>> it more clear what I am talking about.
> 
> Ugh, that sounds like http://sta.li/

That is totally unrelated.


>> It does not ignore specification. It complies with specification.
>> The problem is if it can be implemented sanely.
> 
> How is your "ignore PMS" suggestion complying with the PMS? It is
> not.

You seem to misunderstand my idea. Eclasses are optional helper
classes. PMS does not say you must use this or that eclass. I could
just ignore all eclasses and write my own custom function in my
ebuild. That is valid from PMS point of view, even if QA well yell at
me for that (for good reason).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRZXUkAAoJEFpvPKfnPDWzW64IAKuN9Vz7de8PjX6gIAl4VSG5
osVXgZw2cTXjWpxS2s2XOvCOttRMzz6I/yRDUqB3JZmQkUKL659SLzlHPnAYGqC1
fmv0bndovq1ZVP1EANV0+EggBcGvcoKluj20DWqEdqaCbSMFFnK7wiepKnq7N2hc
y2CSMMh2nsIJQba9wjXeOxjDWm6qC+c67hJFpDQOGl6dRB7rNZIOYHSw0HFekSmX
gQ7Bg4YJMLFYceMceC3sNkqnawnJUyNpEFGy+cWNyD+itcrGFPKxf28ITbidccS1
H8E85ffKI0VQOKx5I3BIor6WIPkGvV68uw2EwkgCT2pORxTH5zHEZZOJh9dNf7Y=
=cxmj
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Tom Wijsman]

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

On Wed, 10 Apr 2013 16:20:20 +0200
hasufell <hasufell@gentoo.org> wrote:

> That environment file saves the whole environment including user
> settings. How does that fit the idea I just posted here? It does not.

"It will be generated as a static ebuild based on the current state of
the eclasses", that's a part of what the environment file does.

> Parts of the code could probably be used, but again: this is not a PM
> problem.

Yet it does implement this behavior, neglecting its existence is bad.
 
> What? You seem to misunderstand what I am saying. I am talking about
> something similar to autoconf which generates a configure file
> depending on the present state of macros/m4 files etc.

Only to be used by 1 eclass and 7 packages? Sounds like an overkill.

> This does not halt eclass development in any way and would only apply
> to _stable_ ebuilds.

Okay, there's a point to that; I missed "once an ebuild goes stable"
the first time and therefore didn't grasp that paragraph the way you
did. I'd agree we would want to pursue such thing and agree on the
advantages for the whole tree; I just thought you were suggesting this
solely for the EAPI 0 problem that the toolchain experiences, context
changes in a discussion are nasty...

> EAPI confusion is the amount of EAPIs a new developer has to know in
> order to understand ebuilds. I am not arguing egainst EAPIs here. This
> is just about eclasses.

Seems we are on par here, the "stop holding on to EAPI 0" is what I
wanted to get clear in order to deal with that confusion.
 
> >   
> > > Now we want to add eclass confusion by introducing versions for
> > > them too?  
> > 
> > Eclasses eventually end up being legacy code because the needs and 
> > usage of them changes over time; so, yes, we will want to write
> > new versions of them and avoid confusion by dropping the older
> > ones. You see the same happen with programming libraries and other
> > fields...
> >   
> > > It's like you would "statically link" the eclasses if that makes
> > > it more clear what I am talking about.
> > 
> > Ugh, that sounds like http://sta.li/
> 
> That is totally unrelated.

Unrelated examples get unrelated answers. Let me give you a relevant:

When you generate ebuilds out of eclasses, you are effectively
generating versions of the current eclass as well. And when someone
experiences a problem that is caused due to an eclass, it will be much
easier to deal with it if we had the eclass in its original form rather
than its generated ebuild form. Actual versions lead to less confusion.

> > > > > Imo we could even ignore PMS here, ...
> > > >
> > > > ... ; this would ignore a specification, ...
> > > 
> > > It does not ignore specification. It complies with specification.
> > > The problem is if it can be implemented sanely.
> > 
> > How is your "ignore PMS" suggestion complying with the PMS? It is
> > not. ...
> 
> You seem to misunderstand my idea.

You state "ignore PMS" and therefore would state that you "ignore the
Package Manager Specification"; then you end up stating the opposite.
If you don't want me to misunderstand your idea, please be consistent.

> Eclasses are optional helper classes. PMS does not say you must use
> this or that eclass. I could just ignore all eclasses and write my
> own custom function in my ebuild. That is valid from PMS point of
> view, even if QA well yell at me for that (for good reason).

Unrelated and you are contradicting your "ignore PMS" statement.

- -- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQEcBAEBAgAGBQJRZX8jAAoJEJWyH81tNOV9ny8IAL5JhXOtZh7sdWw9G9J0Rzn3
LSYiDe+GPj27p7RYroc1LNmIOkPvsME0BbM8evPMlGNBvzUiE7s15Oto94uXgFX5
s9mARk83RfuWGJF7P0rVArnlF8LaOEEPljYOrvaZ1VqgaetWVr4Hri7dBu+qHPTU
h8GcaFiMzspFHW0JxHi1QQyD4v2STfI6guWUripDwpLoB0OadP9/btZYO9eZ3Toy
MlefZ8yj/vINbQv13ex/ev8by+BHFGQWxi1xDX+hekXmZkbIIxWtOKp3P4apAgwg
vAXN6IEbRzmfZloykfTG8KuFfGUgMKVGVTcKHhtSBWHeOY703Ie62+JZnAVJLf8=
=Qo7A
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 10/04/13 11:02 AM, Tom Wijsman wrote:
> On Wed, 10 Apr 2013 16:20:20 +0200 hasufell <hasufell@gentoo.org>
> wrote:
> 
>> That environment file saves the whole environment including user 
>> settings. How does that fit the idea I just posted here? It does
>> not.
> 
> "It will be generated as a static ebuild based on the current state
> of the eclasses", that's a part of what the environment file does.
> 

The environment includes per-system-specific results, though, not just
the result of the ebuild plus insertion of all eclasses listed in the
inherit line(s), no?  Also, we probably don't actually want ALL of the
eclasses to be inlined, just toolchain.



> 
> When you generate ebuilds out of eclasses, you are effectively 
> generating versions of the current eclass as well. And when
> someone experiences a problem that is caused due to an eclass, it
> will be much easier to deal with it if we had the eclass in its
> original form rather than its generated ebuild form. Actual
> versions lead to less confusion.
> 

That is a double-edged sword, though.  What happens if the fix you
need for a more current gcc breaks older ones?  Or likewise, the fix
you need for an older gcc for a small edge-case bug doesn't apply to
newer versions?

I believe what hasufell is suggesting is essentially that we could,
via inlining a snapshot of toolchain.eclass (et al) into stable
ebuilds, implement elcass versioning without having multiple versions
of the actual toolchain.eclass file.  So we get the advantage of
versioning without the nastiness of having to handle and organize
who-knows-how-many toolchain-###.eclass files, with the only drawback
being that changes required to bugfix stable ebuilds would possibly
need to be forward-ported to the eclass if it applies.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlFllsQACgkQ2ugaI38ACPCnUQD9GMBCOetzttYQ7T5iHJU0qjjd
ltNJeCII4XNkdszmkh4BAK0Erb4+P2rdmtzDQXqLuJMTVE3hBQSYaxfD0jcJDng/
=VqXp
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Tom Wijsman]

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

On Wed, 10 Apr 2013 12:43:48 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> The environment includes per-system-specific results, though, not just
> the result of the ebuild plus insertion of all eclasses listed in the
> inherit line(s), no?  Also, we probably don't actually want ALL of the
> eclasses to be inlined, just toolchain.

Yet, you would be solving problems that were already solved.

> That is a double-edged sword, though.  What happens if the fix you
> need for a more current gcc breaks older ones?

It doesn't, because it is versioned it would only apply to the current
one; other than that, fixes to specific versions of gcc should probably
be in the ebuild as long as they are not known to be future proof. 

> Or likewise, the fix
> you need for an older gcc for a small edge-case bug doesn't apply to
> newer versions?

Because it is versioned, I'm not going to repeat myself, see above...
 
> I believe what hasufell is suggesting is essentially that we could,
> via inlining a snapshot of toolchain.eclass (et al) into stable
> ebuilds, implement elcass versioning without having multiple versions
> of the actual toolchain.eclass file.

Yes, as far as I understand it he suggests that; but that is overkill
to do for 1 eclass and 7 packages; the need for multiple versions is
the problem here, not the way eclasses and ebuilds work.

> So we get the advantage of versioning without the nastiness of
> having to handle and organize who-knows-how-many
> toolchain-###.eclass files, with the only drawback being that changes
> required to bugfix stable ebuilds would possibly need to be
> forward-ported to the eclass if it applies.

If you need versioning, a method that is proven to work (ebuilds in the
Portage tree) is not nasty in my eyes. But why introduce the need for
versioning? Other eclasses don't have this problem. Toolchain eclasses
are the ones that are nasty at the moment; it's not PMS, not versioning.

If you need to embed the code in the ebuild in order to keep it
unaffected from unstable / experimental changes when it stabilizes, why
not just permanently move the code to the ebuild instead?

It's pointless to maintain an eclass but not intend to use the eclass
like all the rest of the eclasses are used; also, if the eclass breaks
every time you touch it, then there too much logic in the eclass.

But hey, who cares, this was about EAPI 0 -> 5 in the first place.

- -- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQEcBAEBAgAGBQJRZZ1oAAoJEJWyH81tNOV9QEQH+wQ2Oh8fqzcFwSRTk48d92jP
FQF+NQpIxG8UYPuBpoR9/myGD/hvPpqclGREKkSNPgVuBAbuG26MnTJbJRMwZitR
INHay8Z8rxIca6/GZSKOy2aeLF3xnvKPNLwXsK/Tyghx+0RuBxLi7Ea6AvaVyDrE
JqruJhq5e4uhAQ5Jq7oixPXVu9Vm7X/yvVZ76tovdk4ALG6LZcC5Is0zjtU7Qvou
fF3g90/sqlmCBnpJT+1ir3ZSJJdeglRkdukeqkCPdQekUMgFF+hE6zPxZdp+VBa8
abX43TXkYx0NTCgyzA+Hi1cdD10ofICG1rRusr+8H+2y/kg7WeqHi1gpuwU2yE8=
=W7n7
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Mike Frysinger]

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

On Tuesday 09 April 2013 14:12:33 Donnie Berkholz wrote:
> On 23:20 Mon 08 Apr     , Ryan Hill wrote:
> > Hrm.  I just meant that package eclasses suck. I hate the fact that they
> > effectively make stable moot.  There is no such thing as a stable keyword
> > for a package built by an eclass.  It's like working without a net. 
> > When it's a core system package it's twice as bad.
> > 
> > As far as these eclasses go, toolchain is the worst.  Yes, it is fragile
> > and complex.  It's over a decade's worth of spaghetti code.  It builds 12
> > years of gcc releases.  It's hairy.  Everything depends on everything
> > else, and everything is based on assumptions and implications that may
> > or may not still be relevant.  Making "obviously" correct changes has
> > often broken something somewhere else, time and again.  I'm not telling
> > you this for some kind of perverse bragging rights.  It's not something
> > to be proud of.  I just want you to understand how easy it is to fuck
> > things up.
> > 
> > When it breaks, it breaks stable.  I absolutely hate breaking stable.  I
> > lose sleep over it.
> 
> You could probably deal with this through much more aggressive bumping
> of eclass versions in concert with ebuild bumps, followed by eclass
> freezes once their users go stable.

we can could create a "toolchain-stable.eclass".  whenever we stabilize a new 
version, we copy the current toolchain.eclass to toolchain-stable.eclass and 
change the newly stabilized ebuild to inherit that instead.

for all other versions (unstable, and older stable), we have them use the 
toolchain.eclass.
-mike

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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Rich Freeman]

On Wed, Apr 10, 2013 at 3:30 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> we can could create a "toolchain-stable.eclass".  whenever we stabilize a new
> version, we copy the current toolchain.eclass to toolchain-stable.eclass and
> change the newly stabilized ebuild to inherit that instead.
>
> for all other versions (unstable, and older stable), we have them use the
> toolchain.eclass.

That sounds slightly better than how a few infamous libs handle
SONAMEs and ABIs.

I think the real problem is that we're defining functions without
clearly defining the inputs and outputs.  The input is essentially a
tarball or directory tree that is expected to be in a fairly
particular format, but upstream does not commit to keeping these
formats across versions.

This is like defining a function in an eclass that takes two integers
as parameters, and then in the next eclass revision having it take two
strings.  That is obviously going to create a mess unless you
carefully modify all the references to that function on every bump.
Heaven forbid anybody with an overlay wants to use it.

toolchain.eclass is only used by gcc, kgcc64, and gcc-apple.  Would it
just make more sense to inline it?  That makes all these issues go
away - each version has its own independent quality process and there
is no risk of changes breaking things across versions.

Rich

[gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Ryan Hill]

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

On Wed, 10 Apr 2013 16:22:29 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Wed, Apr 10, 2013 at 3:30 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> > we can could create a "toolchain-stable.eclass".  whenever we stabilize a
> > new version, we copy the current toolchain.eclass to
> > toolchain-stable.eclass and change the newly stabilized ebuild to inherit
> > that instead.

That might worth a shot.

> toolchain.eclass is only used by gcc, kgcc64, and gcc-apple.  Would it
> just make more sense to inline it?  That makes all these issues go
> away - each version has its own independent quality process and there
> is no risk of changes breaking things across versions.

While that's true, we often do make changes that need to be applied to all
versions.  The more each ebuild diverges from each other, the greater the
likelihood of conflicts that will have to be individually inspected.

I used to inline parts of toolchain_src_unpack in the live vcs ebuilds and
I constantly had to sync them to the eclass by hand.  And that's just 3
ebuilds.  There are over 200 of them in the toolchain overlay.


-- 
gcc-porting
toolchain, wxwidgets                                     by design, by neglect
@ gentoo.org                                     for a fact or just for effect

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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Tom Wijsman]

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

On Sat, 6 Apr 2013 20:05:11 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:

> On Sun, 7 Apr 2013 00:37:22 +0200
> "Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
> 
> Every time this comes up we explain why.  Please refer to those
> threads for the complete story.

Which threads?

> In short:
> Toolchain packages, for better or worse, are built by eclass.  We are
> not forward-porting toolchain.eclass every time someone decides there
> are too many EAPIs in the tree.

Did you ever try it?

> Every change to that eclass breaks something (the trick is to break
> things people don't care about any more and hope no one notices).

That's exactly what legacy code does if nobody maintains it. The trick
is to make an end to that soon; because the longer you keep this
around, the more you will break in the future. Are you going to wait
for the moment that changes are really required but can't be applied?

> I don't know the ins and outs of glibc's eblits but I doubt they would
> be simple to port either.  I also don't know much about
> toolchain-binutils.eclass, but it seems like it would be doable.

Someone would know; if not, we'll have to do some re-engineering.

> Other packages are already on later EAPIs.

Cool.

> There is no reason to remove EAPI 0.  Leave it as the baseline that
> other EAPI's are defined by.  Most devs will not be dealing with
> these packages, so it really doesn't affect them.  Since there is no
> reason to remove it, we will continue to use it.

Of course there is a reason, getting rid of unmaintainable legacy code.
That shouldn't be representative as a baseline for current code. Sadly,
I see such ebuilds on more than a weekly basis, you can't really avoid
it give that 25% of the repository consists of it. If you can't refactor
it in place, you may opt to rewrite it in an overlay; in EAPI 5 or 6.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

["Paweł Hajdan, Jr."]

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

On 4/2/13 7:25 AM, Ulrich Mueller wrote:
> We already "encourage" using the newest EAPI, see 20110308 meeting.
> (Though I fail to find this recommendation in the devmanual, shouldn't
> it be there?)
> 
> Should we have a stricter rule? Would such a rule help significantly
> reducing the number of EAPI 0 ebuilds?

Rules do not make things happen, especially not in a situation like here.

Known problems:
- EAPI-0 used to provide an upgrade path (for system packages)
- older EAPIs used because some eclasses do not support more recent EAPIs

Something we could do:
- add a repoman _warning_ (not an error) when an older than latest EAPI
is used; hopefully developers will see that and make a change for
package updates

Paweł


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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Zac Medico]

On 04/02/2013 03:37 PM, "Paweł Hajdan, Jr." wrote:
> On 4/2/13 7:25 AM, Ulrich Mueller wrote:
>> We already "encourage" using the newest EAPI, see 20110308 meeting.
>> (Though I fail to find this recommendation in the devmanual, shouldn't
>> it be there?)
>>
>> Should we have a stricter rule? Would such a rule help significantly
>> reducing the number of EAPI 0 ebuilds?
> 
> Rules do not make things happen, especially not in a situation like here.
> 
> Known problems:
> - EAPI-0 used to provide an upgrade path (for system packages)

This only makes sense as long as we have profiles supporting the
relevant EAPI. Do we still have any EAPI 0 profiles that are relevant?
In profiles/releases/10.0/eapi we have EAPI 2. So, perhaps those system
packages could be using EAPI 2 as well.
-- 
Thanks,
Zac

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Thomas Sachau]

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

Ulrich Mueller schrieb:
> One agenda item I'd like to add myself is EAPI deprecation (again).
> We're collecting items for EAPI 6 already, and with this being
> deployed there would be seven EAPIs in use.
> 
> http://qa-reports.gentoo.org/output/eapi_usage.txt says:
> 
>    repository '/usr/portage':
>      eapi: '4' 12928 pkgs found, 39.10% of the repository
>      eapi: '0' 7041 pkgs found, 21.29% of the repository
>      eapi: 'unsupported' 4630 pkgs found, 14.00% of the repository
>      eapi: '2' 4289 pkgs found, 12.97% of the repository
>      eapi: '3' 3748 pkgs found, 11.34% of the repository
>      eapi: '1' 429 pkgs found, 1.30% of the repository
> 
>    Date generated: Tue Apr  2 13:03:17 UTC 2013
> 
> We already "encourage" using the newest EAPI, see 20110308 meeting.
> (Though I fail to find this recommendation in the devmanual, shouldn't
> it be there?)
> 
> Should we have a stricter rule? Would such a rule help significantly
> reducing the number of EAPI 0 ebuilds?
> 
> Ulrich
> 

If a newer EAPI contains a feature usefull for me, i will update the
EAPI of the ebuild to use this feature, but otherwise, why should i
change the EAPI (and have additional work), when there is no reason?

So what do we gain from a stricter rule forcing the usage of specific
EAPI versions?

-- 

Thomas Sachau
Gentoo Linux Developer


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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Ciaran McCreesh]

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

On Wed, 03 Apr 2013 11:56:35 +0200
Thomas Sachau <tommy@gentoo.org> wrote:
> If a newer EAPI contains a feature usefull for me, i will update the
> EAPI of the ebuild to use this feature, but otherwise, why should i
> change the EAPI (and have additional work), when there is no reason?

Newer EAPIs have better error checking.

-- 
Ciaran McCreesh

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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Thomas Sachau]

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

Ciaran McCreesh schrieb:
> On Wed, 03 Apr 2013 11:56:35 +0200
> Thomas Sachau <tommy@gentoo.org> wrote:
>> If a newer EAPI contains a feature usefull for me, i will update the
>> EAPI of the ebuild to use this feature, but otherwise, why should i
>> change the EAPI (and have additional work), when there is no reason?
> 
> Newer EAPIs have better error checking.
> 

Please show be those better checks.

-- 

Thomas Sachau
Gentoo Linux Developer


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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Ciaran McCreesh]

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

On Wed, 03 Apr 2013 21:06:08 +0200
Thomas Sachau <tommy@gentoo.org> wrote:
> Ciaran McCreesh schrieb:
> > On Wed, 03 Apr 2013 11:56:35 +0200
> > Thomas Sachau <tommy@gentoo.org> wrote:
> >> If a newer EAPI contains a feature usefull for me, i will update
> >> the EAPI of the ebuild to use this feature, but otherwise, why
> >> should i change the EAPI (and have additional work), when there is
> >> no reason?
> > 
> > Newer EAPIs have better error checking.
> 
> Please show be those better checks.

You can see for yourself in PMS. There's a big friendly list
summarising changes between EAPIs. Have a look at, for example,

http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-12900011.3.3.1

-- 
Ciaran McCreesh

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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

[Michał Górny]

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

On Tue, 2 Apr 2013 16:25:19 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> Should we have a stricter rule? Would such a rule help significantly
> reducing the number of EAPI 0 ebuilds?

I'm not sure if that could help. The problem is with people and not
with rules, and I think that if we try to force a stricter rule
on people, they will simply disobey it.

The problem is that some people actually believe that keeping stuff
in EAPI 0 is going to help people upgrading. And they don't accept
the fact that the upgrade path has been broken already and there's
no real point in refusing to use newer features just to keep it
a little less broken.

That said, I'm hoping that EAPI 5 profiles could change something.
But I feel like some people will still oppose, assuming people will
create custom profiles or something like that just to try to update
their system.

And I think our docs still don't mention how to upgrade
from an ancient system. I've opened a bug suggesting to use chroot
for that some time ago but haven't heard on it since. That said, I think
we need a team of dedicated doc-writers.

-- 
Best regards,
Michał Górny

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

[gentoo-project] Council meeting: Tuesday 9 April 2013, *** 19:00 UTC ***

[Ulrich Mueller]

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

The next council meeting will be on Tuesday 9 April 2013 at 19:00 UTC
(note change of time! [1]) in the #gentoo-council channel on Freenode.


Proposed agenda:

1. Introduction and roll call (5 minutes)

2. Change to newer Bash version in ebuilds (15 minutes)

   Take an initial look, and possibly vote on switching to a newer
   Bash version (e.g. 4.2) for the next EAPI [2,3].

3. EAPI deprecation (10 minutes)

   Should we have stricter rules, in order to limit the number of
   EAPIs that are in active usage? [4]

4. Open bugs with council involvement (15 minutes)

     - Bug 457000 "Missing log and summary for 20090122 and 20090625
       council meetings"
     - Bug 464250 "Encourage developers to use the latest EAPI"

5. Open floor

Regards,
Ulrich


[1] http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900
[2] http://article.gmane.org/gmane.linux.gentoo.project/2371
[3] https://bugs.gentoo.org/431340
[4] http://article.gmane.org/gmane.linux.gentoo.project/2377

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