| 1 |
-----BEGIN PGP SIGNED MESSAGE-----
|
| 2 |
Hash: SHA1
|
| 3 |
|
| 4 |
On Wed, 10 Apr 2013 12:43:48 -0400
|
| 5 |
Ian Stakenvicius <axs@g.o> wrote:
|
| 6 |
|
| 7 |
> The environment includes per-system-specific results, though, not just |
| 8 |
> the result of the ebuild plus insertion of all eclasses listed in the |
| 9 |
> inherit line(s), no? Also, we probably don't actually want ALL of the |
| 10 |
> eclasses to be inlined, just toolchain. |
| 11 |
|
| 12 |
Yet, you would be solving problems that were already solved.
|
| 13 |
|
| 14 |
> That is a double-edged sword, though. What happens if the fix you |
| 15 |
> need for a more current gcc breaks older ones? |
| 16 |
|
| 17 |
It doesn't, because it is versioned it would only apply to the current
|
| 18 |
one; other than that, fixes to specific versions of gcc should probably
|
| 19 |
be in the ebuild as long as they are not known to be future proof.
|
| 20 |
|
| 21 |
> Or likewise, the fix |
| 22 |
> you need for an older gcc for a small edge-case bug doesn't apply to |
| 23 |
> newer versions? |
| 24 |
|
| 25 |
Because it is versioned, I'm not going to repeat myself, see above...
|
| 26 |
|
| 27 |
> I believe what hasufell is suggesting is essentially that we could, |
| 28 |
> via inlining a snapshot of toolchain.eclass (et al) into stable |
| 29 |
> ebuilds, implement elcass versioning without having multiple versions |
| 30 |
> of the actual toolchain.eclass file. |
| 31 |
|
| 32 |
Yes, as far as I understand it he suggests that; but that is overkill
|
| 33 |
to do for 1 eclass and 7 packages; the need for multiple versions is
|
| 34 |
the problem here, not the way eclasses and ebuilds work.
|
| 35 |
|
| 36 |
> So we get the advantage of versioning without the nastiness of |
| 37 |
> having to handle and organize who-knows-how-many |
| 38 |
> toolchain-###.eclass files, with the only drawback being that changes |
| 39 |
> required to bugfix stable ebuilds would possibly need to be |
| 40 |
> forward-ported to the eclass if it applies. |
| 41 |
|
| 42 |
If you need versioning, a method that is proven to work (ebuilds in the
|
| 43 |
Portage tree) is not nasty in my eyes. But why introduce the need for
|
| 44 |
versioning? Other eclasses don't have this problem. Toolchain eclasses
|
| 45 |
are the ones that are nasty at the moment; it's not PMS, not versioning.
|
| 46 |
|
| 47 |
If you need to embed the code in the ebuild in order to keep it
|
| 48 |
unaffected from unstable / experimental changes when it stabilizes, why
|
| 49 |
not just permanently move the code to the ebuild instead?
|
| 50 |
|
| 51 |
It's pointless to maintain an eclass but not intend to use the eclass
|
| 52 |
like all the rest of the eclasses are used; also, if the eclass breaks
|
| 53 |
every time you touch it, then there too much logic in the eclass.
|
| 54 |
|
| 55 |
But hey, who cares, this was about EAPI 0 -> 5 in the first place.
|
| 56 |
|
| 57 |
- --
|
| 58 |
With kind regards,
|
| 59 |
|
| 60 |
Tom Wijsman (TomWij)
|
| 61 |
Gentoo Developer
|
| 62 |
|
| 63 |
E-mail address : TomWij@g.o
|
| 64 |
GPG Public Key : 6D34E57D
|
| 65 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
|
| 66 |
-----BEGIN PGP SIGNATURE-----
|
| 67 |
Version: GnuPG v2.0.19 (GNU/Linux)
|
| 68 |
|
| 69 |
iQEcBAEBAgAGBQJRZZ1oAAoJEJWyH81tNOV9QEQH+wQ2Oh8fqzcFwSRTk48d92jP
|
| 70 |
FQF+NQpIxG8UYPuBpoR9/myGD/hvPpqclGREKkSNPgVuBAbuG26MnTJbJRMwZitR
|
| 71 |
INHay8Z8rxIca6/GZSKOy2aeLF3xnvKPNLwXsK/Tyghx+0RuBxLi7Ea6AvaVyDrE
|
| 72 |
JqruJhq5e4uhAQ5Jq7oixPXVu9Vm7X/yvVZ76tovdk4ALG6LZcC5Is0zjtU7Qvou
|
| 73 |
fF3g90/sqlmCBnpJT+1ir3ZSJJdeglRkdukeqkCPdQekUMgFF+hE6zPxZdp+VBa8
|
| 74 |
abX43TXkYx0NTCgyzA+Hi1cdD10ofICG1rRusr+8H+2y/kg7WeqHi1gpuwU2yE8=
|
| 75 |
=W7n7
|
| 76 |
-----END PGP SIGNATURE----- |
Archives