| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 25/08/13 10:30 AM, Michał Górny wrote: |
| 5 |
> Dnia 2013-08-25, o godz. 16:15:31 Ulrich Mueller <ulm@g.o> |
| 6 |
> napisał(a): |
| 7 |
> |
| 8 |
>>>>>>> On Sun, 25 Aug 2013, Thomas Sachau wrote: |
| 9 |
>> |
| 10 |
>>> first version (multilib1.patch) directly changes the output of |
| 11 |
>>> the currently used multilib_is_native_abi() function: |
| 12 |
>> |
| 13 |
>> I think this would be very misleading. If a function is called |
| 14 |
>> multilib_is_native_abi then it should test for exactly that, not |
| 15 |
>> for something else. |
| 16 |
> |
| 17 |
> It's for multilib-portage. It hacks over everything in the |
| 18 |
> environment. None of multilib variables are really meaningful in |
| 19 |
> this context, so I don't have a problem with hacking that |
| 20 |
> behavior. |
| 21 |
> |
| 22 |
|
| 23 |
Multilib-portage could just override the definition of |
| 24 |
multilib_is_native_abi so that it's always true -- this change isn't |
| 25 |
necessary for that particular use case. It *is* necessary to support |
| 26 |
end-users that want to do what multilib-portage offers but just with |
| 27 |
regular portage. |
| 28 |
|
| 29 |
|
| 30 |
-----BEGIN PGP SIGNATURE----- |
| 31 |
Version: GnuPG v2.0.20 (GNU/Linux) |
| 32 |
|
| 33 |
iF4EAREIAAYFAlIbYWkACgkQ2ugaI38ACPDjKwEAq5Ocxg4NItUkZ+qS+4Hj2iag |
| 34 |
zVqJpa0E2oDDAyXpK5IBAIR7S0NOfHuN3hd/5fVNKebxdlwUo4yPee8rWFHv8Q48 |
| 35 |
=dqDh |
| 36 |
-----END PGP SIGNATURE----- |
Archives