| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On 04/10/2013 03:00 PM, Tom Wijsman wrote: |
| 5 |
> On Wed, 10 Apr 2013 14:20:08 +0200 hasufell <hasufell@g.o> |
| 6 |
> wrote: |
| 7 |
> |
| 8 |
>> That will introduce a few problems (such as how to handle global |
| 9 |
>> eclass scope), but I think they are solvable. |
| 10 |
> |
| 11 |
> Portage has solved these problems, no need to solve hem again. |
| 12 |
|
| 13 |
It has not, because it's not a problem on PM level. |
| 14 |
|
| 15 |
> |
| 16 |
> Eclasses aren't meant to be used like this, there will surely be |
| 17 |
> some trouble when going through with this; why take this meta |
| 18 |
> approach if you could rewrite the eclass itself instead and make it |
| 19 |
> conform? |
| 20 |
|
| 21 |
To ensure that code _behind_ a stable ebuild does not change. EAPI |
| 22 |
versions already try to solve this and that's why we have EAPI |
| 23 |
confusion. Now we want to add eclass confusion by introducing versions |
| 24 |
for them too? |
| 25 |
|
| 26 |
It's like you would "statically link" the eclasses if that makes it |
| 27 |
more clear what I am talking about. |
| 28 |
|
| 29 |
> |
| 30 |
>> Imo we could even ignore PMS here, since we would basically just |
| 31 |
>> dump all related eclass functions into the ebuild and drop the |
| 32 |
>> eclass inherit. We could write a tool to do and revert that and |
| 33 |
>> make it more readable etc. |
| 34 |
> |
| 35 |
> I don't think that this is the way we should cope with legacy |
| 36 |
> code. |
| 37 |
> |
| 38 |
> This makes the situation even worse; this would ignore a |
| 39 |
> specification, re-implement something we already have in Portage |
| 40 |
> and lead to code that can't and shouldn't be re-used. I think time |
| 41 |
> is better spent on making it work with Portage than to waste time |
| 42 |
> reinventing parts of Portage. |
| 43 |
> |
| 44 |
|
| 45 |
It does not ignore specification. It complies with specification. The |
| 46 |
problem is if it can be implemented sanely. |
| 47 |
-----BEGIN PGP SIGNATURE----- |
| 48 |
Version: GnuPG v2.0.19 (GNU/Linux) |
| 49 |
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ |
| 50 |
|
| 51 |
iQEcBAEBAgAGBQJRZWZKAAoJEFpvPKfnPDWzMoUIAJWTudQ1/3UmZtJhvkttsgb5 |
| 52 |
GZS34RIU86VjntSpDgmkPGwkRcCxPoV2IjOuWq8l4+mhFo3imlI9pcpPiKyZpNZD |
| 53 |
j8Fw/fJjiDs2+Qc7OeND64TZzGzTiFYGhzNnEN5AbDrUhvBUf9Mnyk1/EB6AXRhX |
| 54 |
uTDYIQIO5PyZ9fY+N9aTX0GxfgKQZdh06j3t350hgwBDyGJCl/96Nl+UBRLBFrQ6 |
| 55 |
g9s5Hp7cYxvQ/lvi7zIfuZzqWgS5j6eqxL3gF0qDiqVk9PcOLZaoxlNg9IqWtAWk |
| 56 |
ZyAHmrLa3RQiLLSsojAg5TrtmQKmDvaOvaKwpiMe+AsViDFYIFOhSnvFRl8Oglc= |
| 57 |
=vWvj |
| 58 |
-----END PGP SIGNATURE----- |
Archives