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

[Tom Wijsman <TomWij@gentoo.org>]

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