| 1 |
On Tue, 17 Sep 2013 14:38:08 +0200 |
| 2 |
Thomas Sachau <tommy@g.o> wrote: |
| 3 |
|
| 4 |
> Alexis Ballier schrieb: |
| 5 |
> > just to be clear: I prefer the 1st patch but I would give the |
| 6 |
> > variable (COMPLETE_MULTILIB) a more private name and document this |
| 7 |
> > is only for multilib-portage and it will not work with regular |
| 8 |
> > portage. |
| 9 |
> > |
| 10 |
> > |
| 11 |
> |
| 12 |
> Since you only argued against such implementation in general, but did |
| 13 |
> not write any reasoning behind your choice, not much i could get out |
| 14 |
> of this. |
| 15 |
|
| 16 |
|
| 17 |
you simply ignored it... |
| 18 |
|
| 19 |
http://article.gmane.org/gmane.linux.gentoo.devel/87862 |
| 20 |
|
| 21 |
> I have been doing the second choice now, as written in my answer to |
| 22 |
> Ian. |
| 23 |
> |
| 24 |
> For your variable request: |
| 25 |
> |
| 26 |
> I left it this way, since it is intended for end users, who use |
| 27 |
> regular portage. |
| 28 |
|
| 29 |
it's certainly not intended that way in its current state; maybe you |
| 30 |
believe it is or want to make it that way but the truth is that if |
| 31 |
regular users set this variable with regular portage they end up with |
| 32 |
broken deps and packages failing to build... |
| 33 |
|
| 34 |
> In addition, it is a cleaner solution for |
| 35 |
> multilib-portage, since i dont have to internally overwrite an eclass |
| 36 |
> function, but that is just a side effect, since this issue never |
| 37 |
> blocked multilib-portage. |
| 38 |
|
| 39 |
I understood this, hence the request for a more private name in order |
| 40 |
not to make your work harder... |
Archives