| 1 |
-----BEGIN PGP SIGNED MESSAGE-----
|
| 2 |
Hash: SHA1
|
| 3 |
|
| 4 |
On Wed, 10 Apr 2013 16:20:20 +0200
|
| 5 |
hasufell <hasufell@g.o> wrote:
|
| 6 |
|
| 7 |
> That environment file saves the whole environment including user |
| 8 |
> settings. How does that fit the idea I just posted here? It does not. |
| 9 |
|
| 10 |
"It will be generated as a static ebuild based on the current state of
|
| 11 |
the eclasses", that's a part of what the environment file does.
|
| 12 |
|
| 13 |
> Parts of the code could probably be used, but again: this is not a PM |
| 14 |
> problem. |
| 15 |
|
| 16 |
Yet it does implement this behavior, neglecting its existence is bad.
|
| 17 |
|
| 18 |
> What? You seem to misunderstand what I am saying. I am talking about |
| 19 |
> something similar to autoconf which generates a configure file |
| 20 |
> depending on the present state of macros/m4 files etc. |
| 21 |
|
| 22 |
Only to be used by 1 eclass and 7 packages? Sounds like an overkill.
|
| 23 |
|
| 24 |
> This does not halt eclass development in any way and would only apply |
| 25 |
> to _stable_ ebuilds. |
| 26 |
|
| 27 |
Okay, there's a point to that; I missed "once an ebuild goes stable"
|
| 28 |
the first time and therefore didn't grasp that paragraph the way you
|
| 29 |
did. I'd agree we would want to pursue such thing and agree on the
|
| 30 |
advantages for the whole tree; I just thought you were suggesting this
|
| 31 |
solely for the EAPI 0 problem that the toolchain experiences, context
|
| 32 |
changes in a discussion are nasty...
|
| 33 |
|
| 34 |
> EAPI confusion is the amount of EAPIs a new developer has to know in |
| 35 |
> order to understand ebuilds. I am not arguing egainst EAPIs here. This |
| 36 |
> is just about eclasses. |
| 37 |
|
| 38 |
Seems we are on par here, the "stop holding on to EAPI 0" is what I
|
| 39 |
wanted to get clear in order to deal with that confusion.
|
| 40 |
|
| 41 |
> > |
| 42 |
> > > Now we want to add eclass confusion by introducing versions for |
| 43 |
> > > them too? |
| 44 |
> > |
| 45 |
> > Eclasses eventually end up being legacy code because the needs and |
| 46 |
> > usage of them changes over time; so, yes, we will want to write |
| 47 |
> > new versions of them and avoid confusion by dropping the older |
| 48 |
> > ones. You see the same happen with programming libraries and other |
| 49 |
> > fields... |
| 50 |
> > |
| 51 |
> > > It's like you would "statically link" the eclasses if that makes |
| 52 |
> > > it more clear what I am talking about. |
| 53 |
> > |
| 54 |
> > Ugh, that sounds like http://sta.li/ |
| 55 |
> |
| 56 |
> That is totally unrelated. |
| 57 |
|
| 58 |
Unrelated examples get unrelated answers. Let me give you a relevant:
|
| 59 |
|
| 60 |
When you generate ebuilds out of eclasses, you are effectively
|
| 61 |
generating versions of the current eclass as well. And when someone
|
| 62 |
experiences a problem that is caused due to an eclass, it will be much
|
| 63 |
easier to deal with it if we had the eclass in its original form rather
|
| 64 |
than its generated ebuild form. Actual versions lead to less confusion.
|
| 65 |
|
| 66 |
> > > > > Imo we could even ignore PMS here, ... |
| 67 |
> > > > |
| 68 |
> > > > ... ; this would ignore a specification, ... |
| 69 |
> > > |
| 70 |
> > > It does not ignore specification. It complies with specification. |
| 71 |
> > > The problem is if it can be implemented sanely. |
| 72 |
> > |
| 73 |
> > How is your "ignore PMS" suggestion complying with the PMS? It is |
| 74 |
> > not. ... |
| 75 |
> |
| 76 |
> You seem to misunderstand my idea. |
| 77 |
|
| 78 |
You state "ignore PMS" and therefore would state that you "ignore the
|
| 79 |
Package Manager Specification"; then you end up stating the opposite.
|
| 80 |
If you don't want me to misunderstand your idea, please be consistent.
|
| 81 |
|
| 82 |
> Eclasses are optional helper classes. PMS does not say you must use |
| 83 |
> this or that eclass. I could just ignore all eclasses and write my |
| 84 |
> own custom function in my ebuild. That is valid from PMS point of |
| 85 |
> view, even if QA well yell at me for that (for good reason). |
| 86 |
|
| 87 |
Unrelated and you are contradicting your "ignore PMS" statement.
|
| 88 |
|
| 89 |
- --
|
| 90 |
With kind regards,
|
| 91 |
|
| 92 |
Tom Wijsman (TomWij)
|
| 93 |
Gentoo Developer
|
| 94 |
|
| 95 |
E-mail address : TomWij@g.o
|
| 96 |
GPG Public Key : 6D34E57D
|
| 97 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
|
| 98 |
-----BEGIN PGP SIGNATURE-----
|
| 99 |
Version: GnuPG v2.0.19 (GNU/Linux)
|
| 100 |
|
| 101 |
iQEcBAEBAgAGBQJRZX8jAAoJEJWyH81tNOV9ny8IAL5JhXOtZh7sdWw9G9J0Rzn3
|
| 102 |
LSYiDe+GPj27p7RYroc1LNmIOkPvsME0BbM8evPMlGNBvzUiE7s15Oto94uXgFX5
|
| 103 |
s9mARk83RfuWGJF7P0rVArnlF8LaOEEPljYOrvaZ1VqgaetWVr4Hri7dBu+qHPTU
|
| 104 |
h8GcaFiMzspFHW0JxHi1QQyD4v2STfI6guWUripDwpLoB0OadP9/btZYO9eZ3Toy
|
| 105 |
MlefZ8yj/vINbQv13ex/ev8by+BHFGQWxi1xDX+hekXmZkbIIxWtOKp3P4apAgwg
|
| 106 |
vAXN6IEbRzmfZloykfTG8KuFfGUgMKVGVTcKHhtSBWHeOY703Ie62+JZnAVJLf8=
|
| 107 |
=Qo7A
|
| 108 |
-----END PGP SIGNATURE----- |
Archives