| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 21/11/12 10:17 AM, Gilles Dartiguelongue wrote: |
| 5 |
> Le mercredi 21 novembre 2012 à 08:54 -0500, Ian Stakenvicius a |
| 6 |
> écrit : |
| 7 |
>> On 21/11/12 04:43 AM, Michał Górny wrote: |
| 8 |
>>> Moved: python_export, getters, python_domodule, python_doscript |
| 9 |
>>> and the necessary internal functions. No global-scope |
| 10 |
>>> variables, no phase functions. [ Snip! ] |
| 11 |
>> |
| 12 |
>> So remind me again, in 10 words or less, why these shouldn't all |
| 13 |
>> stay in python-r1.eclass? ie, what use case do we have for |
| 14 |
>> using python-utils-r1 but not python-r1 (or vice-versa, depending |
| 15 |
>> on which one inherits the other)? |
| 16 |
> |
| 17 |
> From "[gentoo-dev] python-r1.eclass: the masterplan (dirty RFC)" |
| 18 |
> email: |
| 19 |
> |
| 20 |
> Le lundi 12 novembre 2012 à 15:43 +0100, Michał Górny a écrit : |
| 21 |
>> 1) splitting common functions into python-utils-r1. |
| 22 |
>> |
| 23 |
>> The python-utils-r1 eclass would provide means to work with |
| 24 |
>> specific Python packages like portage. Unlike python-r1, it would |
| 25 |
>> not export IUSE or require any specific USE flags. |
| 26 |
>> |
| 27 |
>> I'm not insisting on this nor giving it a very high priority. It |
| 28 |
>> is a straightforward change since python-r1 will inherit the new |
| 29 |
>> eclass anyway. |
| 30 |
> |
| 31 |
> |
| 32 |
|
| 33 |
|
| 34 |
Ahh ok, so only very specific tools for very specific use cases. |
| 35 |
-----BEGIN PGP SIGNATURE----- |
| 36 |
Version: GnuPG v2.0.19 (GNU/Linux) |
| 37 |
|
| 38 |
iF4EAREIAAYFAlCs85UACgkQ2ugaI38ACPCxHwD9FvHW2Ke/lcsTDomAIOpEqreH |
| 39 |
Vo6YDYUeDTm2GlBhA4cA/1yG0Fkh+7MNBZc31naOAvL7rh51Xhj8KxHHDuPsfKyC |
| 40 |
=qsUS |
| 41 |
-----END PGP SIGNATURE----- |
Archives