| 1 |
On Tue, 20 Sep 2016 09:15:50 +0200 |
| 2 |
Michał Górny <mgorny@g.o> wrote: |
| 3 |
|
| 4 |
> That said, I don't find the current solution really optimal. A lot of |
| 5 |
> ebuilds (mine, for example) are not using elibtoolize, and I expect |
| 6 |
> that they may randomly fail for some people in corner cases. But I |
| 7 |
> don't feel like adding another eclass to all ebuilds in the tree is |
| 8 |
> a good idea. |
| 9 |
> |
| 10 |
> Portage already does some configure updates in econf. How about we |
| 11 |
> move the whole thing straight into Portage, implicitly activated by |
| 12 |
> econf? That would certainly increase coverage, remove some QA |
| 13 |
> violations from ECLASSDIR and possibly solve the problem long-term. |
| 14 |
> |
| 15 |
> What do you think? |
| 16 |
|
| 17 |
I support this. I don't know if it's as big a problem as it was when I |
| 18 |
last looked at it but cross-compiling often failed without the sysroot |
| 19 |
patch. Much like you, before becoming a dev, I did not want to file a |
| 20 |
whole string of bug reports requesting that elibtoolize be added to |
| 21 |
loads of ebuilds. |
| 22 |
|
| 23 |
-- |
| 24 |
James Le Cuirot (chewi) |
| 25 |
Gentoo Linux Developer |
Archives