| 1 |
-----BEGIN PGP SIGNED MESSAGE-----
|
| 2 |
Hash: SHA1
|
| 3 |
|
| 4 |
On Wed, 10 Apr 2013 15:16:58 +0200
|
| 5 |
hasufell <hasufell@g.o> wrote:
|
| 6 |
|
| 7 |
> It has not, because it's not a problem on PM level. |
| 8 |
|
| 9 |
So that environment file is magic that comes from nowhere?
|
| 10 |
|
| 11 |
> To ensure that code _behind_ a stable ebuild does not change. |
| 12 |
|
| 13 |
Eclasses that do not evolve, that's a new thing. They'll have to
|
| 14 |
eventually evolve anyway, or are we putting a halt to innovation?
|
| 15 |
|
| 16 |
> EAPI versions already try to solve this and that's why we have EAPI |
| 17 |
> confusion. |
| 18 |
|
| 19 |
What exactly is EAPI confusion? If everyone just uses the latest one and
|
| 20 |
stop holding on to EAPI 0 you wouldn't have any kind of confusion, this
|
| 21 |
is what deprecation of the older EAPIs is all about.
|
| 22 |
|
| 23 |
> Now we want to add eclass confusion by introducing versions for them |
| 24 |
> too? |
| 25 |
|
| 26 |
Eclasses eventually end up being legacy code because the needs and
|
| 27 |
usage of them changes over time; so, yes, we will want to write new
|
| 28 |
versions of them and avoid confusion by dropping the older ones. You
|
| 29 |
see the same happen with programming libraries and other fields...
|
| 30 |
|
| 31 |
> It's like you would "statically link" the eclasses if that makes it |
| 32 |
> more clear what I am talking about. |
| 33 |
|
| 34 |
Ugh, that sounds like http://sta.li/
|
| 35 |
|
| 36 |
Statically linking is all shiny, but how does it solve the problem?
|
| 37 |
|
| 38 |
> It does not ignore specification. It complies with specification. The |
| 39 |
> problem is if it can be implemented sanely. |
| 40 |
|
| 41 |
How is your "ignore PMS" suggestion complying with the PMS? It is not.
|
| 42 |
|
| 43 |
The problem is not the implementation, but whether to re-implement it.
|
| 44 |
We're talking about one eclass and some packages here, not the tree;
|
| 45 |
therefore it be a waste of effort time to write this tool, better spend
|
| 46 |
on actually dealing with the problem this thread tries to address.
|
| 47 |
|
| 48 |
It ignores PMS, it ignores the fact it is legacy code, it ignores that
|
| 49 |
it blocks deprecation of the EAPI, it breaks easily; the list goes on.
|
| 50 |
|
| 51 |
- --
|
| 52 |
With kind regards,
|
| 53 |
|
| 54 |
Tom Wijsman (TomWij)
|
| 55 |
Gentoo Developer
|
| 56 |
|
| 57 |
E-mail address : TomWij@g.o
|
| 58 |
GPG Public Key : 6D34E57D
|
| 59 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
|
| 60 |
-----BEGIN PGP SIGNATURE-----
|
| 61 |
Version: GnuPG v2.0.19 (GNU/Linux)
|
| 62 |
|
| 63 |
iQEcBAEBAgAGBQJRZWvpAAoJEJWyH81tNOV9/F0H/inIjulzWmv607Rb/Pu0sz6u
|
| 64 |
SOtNd6IW9C6vmArZcYxPxa8MzfN2sUSHiFjd9EQsgwZrpHe5hxBTHyxqgqM2syHv
|
| 65 |
PIbKeJAFWfJyv/74dF+le0u9KpwgJJtnDaqE56I6YQ+x0R66MHyFXDlf6FMZTTAc
|
| 66 |
pbsTssw3wkhjvhqaW2iqMIFW0I+OiUd15AmX0Ajg09IWdXdhI+EIpA3/5v+5OA1S
|
| 67 |
mvDODLrzvRqN9vUPGKvOnvhrS3EaFpR6g13noDSKM4Z8046BtoXlFI9SwJKXqilT
|
| 68 |
m0FZR6K2g2QbzJGh6uZW38mDtSpaRGNK/ebMFRnxhx/hKfIMu6iXbQMiVmot4WY=
|
| 69 |
=XwQf
|
| 70 |
-----END PGP SIGNATURE----- |
Archives