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 12:43:48 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> The environment includes per-system-specific results, though, not just
> the result of the ebuild plus insertion of all eclasses listed in the
> inherit line(s), no?  Also, we probably don't actually want ALL of the
> eclasses to be inlined, just toolchain.

Yet, you would be solving problems that were already solved.

> That is a double-edged sword, though.  What happens if the fix you
> need for a more current gcc breaks older ones?

It doesn't, because it is versioned it would only apply to the current
one; other than that, fixes to specific versions of gcc should probably
be in the ebuild as long as they are not known to be future proof. 

> Or likewise, the fix
> you need for an older gcc for a small edge-case bug doesn't apply to
> newer versions?

Because it is versioned, I'm not going to repeat myself, see above...
 
> I believe what hasufell is suggesting is essentially that we could,
> via inlining a snapshot of toolchain.eclass (et al) into stable
> ebuilds, implement elcass versioning without having multiple versions
> of the actual toolchain.eclass file.

Yes, as far as I understand it he suggests that; but that is overkill
to do for 1 eclass and 7 packages; the need for multiple versions is
the problem here, not the way eclasses and ebuilds work.

> So we get the advantage of versioning without the nastiness of
> having to handle and organize who-knows-how-many
> toolchain-###.eclass files, with the only drawback being that changes
> required to bugfix stable ebuilds would possibly need to be
> forward-ported to the eclass if it applies.

If you need versioning, a method that is proven to work (ebuilds in the
Portage tree) is not nasty in my eyes. But why introduce the need for
versioning? Other eclasses don't have this problem. Toolchain eclasses
are the ones that are nasty at the moment; it's not PMS, not versioning.

If you need to embed the code in the ebuild in order to keep it
unaffected from unstable / experimental changes when it stabilizes, why
not just permanently move the code to the ebuild instead?

It's pointless to maintain an eclass but not intend to use the eclass
like all the rest of the eclasses are used; also, if the eclass breaks
every time you touch it, then there too much logic in the eclass.

But hey, who cares, this was about EAPI 0 -> 5 in the first place.

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

iQEcBAEBAgAGBQJRZZ1oAAoJEJWyH81tNOV9QEQH+wQ2Oh8fqzcFwSRTk48d92jP
FQF+NQpIxG8UYPuBpoR9/myGD/hvPpqclGREKkSNPgVuBAbuG26MnTJbJRMwZitR
INHay8Z8rxIca6/GZSKOy2aeLF3xnvKPNLwXsK/Tyghx+0RuBxLi7Ea6AvaVyDrE
JqruJhq5e4uhAQ5Jq7oixPXVu9Vm7X/yvVZ76tovdk4ALG6LZcC5Is0zjtU7Qvou
fF3g90/sqlmCBnpJT+1ir3ZSJJdeglRkdukeqkCPdQekUMgFF+hE6zPxZdp+VBa8
abX43TXkYx0NTCgyzA+Hi1cdD10ofICG1rRusr+8H+2y/kg7WeqHi1gpuwU2yE8=
=W7n7
-----END PGP SIGNATURE-----