| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On 04/10/2013 03:40 PM, Tom Wijsman wrote: |
| 5 |
> On Wed, 10 Apr 2013 15:16:58 +0200 hasufell <hasufell@g.o> |
| 6 |
> wrote: |
| 7 |
> |
| 8 |
>> It has not, because it's not a problem on PM level. |
| 9 |
> |
| 10 |
> So that environment file is magic that comes from nowhere? |
| 11 |
|
| 12 |
That environment file saves the whole environment including user |
| 13 |
settings. How does that fit the idea I just posted here? It does not. |
| 14 |
|
| 15 |
Parts of the code could probably be used, but again: this is not a PM |
| 16 |
problem. |
| 17 |
|
| 18 |
> |
| 19 |
>> To ensure that code _behind_ a stable ebuild does not change. |
| 20 |
> |
| 21 |
> Eclasses that do not evolve, that's a new thing. They'll have to |
| 22 |
> eventually evolve anyway, or are we putting a halt to innovation? |
| 23 |
|
| 24 |
What? You seem to misunderstand what I am saying. I am talking about |
| 25 |
something similar to autoconf which generates a configure file |
| 26 |
depending on the present state of macros/m4 files etc. |
| 27 |
|
| 28 |
This does not halt eclass development in any way and would only apply |
| 29 |
to _stable_ ebuilds. |
| 30 |
|
| 31 |
> |
| 32 |
>> EAPI versions already try to solve this and that's why we have |
| 33 |
>> EAPI confusion. |
| 34 |
> |
| 35 |
> What exactly is EAPI confusion? If everyone just uses the latest |
| 36 |
> one and stop holding on to EAPI 0 you wouldn't have any kind of |
| 37 |
> confusion, this is what deprecation of the older EAPIs is all |
| 38 |
> about. |
| 39 |
|
| 40 |
EAPI confusion is the amount of EAPIs a new developer has to know in |
| 41 |
order to understand ebuilds. I am not arguing egainst EAPIs here. This |
| 42 |
is just about eclasses. |
| 43 |
|
| 44 |
> |
| 45 |
>> Now we want to add eclass confusion by introducing versions for |
| 46 |
>> them too? |
| 47 |
> |
| 48 |
> Eclasses eventually end up being legacy code because the needs and |
| 49 |
> usage of them changes over time; so, yes, we will want to write |
| 50 |
> new versions of them and avoid confusion by dropping the older |
| 51 |
> ones. You see the same happen with programming libraries and other |
| 52 |
> fields... |
| 53 |
> |
| 54 |
>> It's like you would "statically link" the eclasses if that makes |
| 55 |
>> it more clear what I am talking about. |
| 56 |
> |
| 57 |
> Ugh, that sounds like http://sta.li/ |
| 58 |
|
| 59 |
That is totally unrelated. |
| 60 |
|
| 61 |
|
| 62 |
>> It does not ignore specification. It complies with specification. |
| 63 |
>> The problem is if it can be implemented sanely. |
| 64 |
> |
| 65 |
> How is your "ignore PMS" suggestion complying with the PMS? It is |
| 66 |
> not. |
| 67 |
|
| 68 |
You seem to misunderstand my idea. Eclasses are optional helper |
| 69 |
classes. PMS does not say you must use this or that eclass. I could |
| 70 |
just ignore all eclasses and write my own custom function in my |
| 71 |
ebuild. That is valid from PMS point of view, even if QA well yell at |
| 72 |
me for that (for good reason). |
| 73 |
-----BEGIN PGP SIGNATURE----- |
| 74 |
Version: GnuPG v2.0.19 (GNU/Linux) |
| 75 |
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ |
| 76 |
|
| 77 |
iQEcBAEBAgAGBQJRZXUkAAoJEFpvPKfnPDWzW64IAKuN9Vz7de8PjX6gIAl4VSG5 |
| 78 |
osVXgZw2cTXjWpxS2s2XOvCOttRMzz6I/yRDUqB3JZmQkUKL659SLzlHPnAYGqC1 |
| 79 |
fmv0bndovq1ZVP1EANV0+EggBcGvcoKluj20DWqEdqaCbSMFFnK7wiepKnq7N2hc |
| 80 |
y2CSMMh2nsIJQba9wjXeOxjDWm6qC+c67hJFpDQOGl6dRB7rNZIOYHSw0HFekSmX |
| 81 |
gQ7Bg4YJMLFYceMceC3sNkqnawnJUyNpEFGy+cWNyD+itcrGFPKxf28ITbidccS1 |
| 82 |
H8E85ffKI0VQOKx5I3BIor6WIPkGvV68uw2EwkgCT2pORxTH5zHEZZOJh9dNf7Y= |
| 83 |
=cxmj |
| 84 |
-----END PGP SIGNATURE----- |
Archives