| 1 |
On Mon, 26 Sep 2016 17:53:43 +0200 |
| 2 |
Alexis Ballier <aballier@g.o> wrote: |
| 3 |
|
| 4 |
> I doubt including elibtoolize in portage/econf/pms is a viable |
| 5 |
> solution: there is way too much code, N patches times M libtool |
| 6 |
> versions to handle, and in rare cases one needs to call elibtoolize |
| 7 |
> with some optional arguments. Specing that would be a pain for no real |
| 8 |
> gain. |
| 9 |
|
| 10 |
Having just looked at the code a bit closer, I see what you mean but… |
| 11 |
|
| 12 |
> On the other hand, we could go the complete opposite direction of what |
| 13 |
> has been done in the past years with PMS: provide a generic way to |
| 14 |
> extend ebuild env from profiles, with the ability to "include" |
| 15 |
> some "eclasses", define default phases and pre/post phases hooks. This |
| 16 |
> would have, e.g., saved the need to completely rewrite and spec |
| 17 |
> epatch, avoided every PM to copy/paste default phases implementations |
| 18 |
> from PMS, etc. However, this has somewhat the same disadvantage than |
| 19 |
> eclasses: one commits crap there and breaks every system in subtle |
| 20 |
> ways... |
| 21 |
|
| 22 |
I don't think I want to open this can of worms either. :( |
| 23 |
|
| 24 |
You said that flameeyes raised this about 10 years ago. It has indeed |
| 25 |
been 10 years! |
| 26 |
|
| 27 |
https://archives.gentoo.org/gentoo-dev/message/caa153de0d23dc264330f5e702f26e58 |
| 28 |
|
| 29 |
The solution he preferred back then was to split elibtoolize into its |
| 30 |
own package and have Portage depend on it. I hadn't considered that and |
| 31 |
I quite like it too. There was only one brief reply to the thread back |
| 32 |
then. Can you think of any downsides now? |
| 33 |
|
| 34 |
-- |
| 35 |
James Le Cuirot (chewi) |
| 36 |
Gentoo Linux Developer |
Archives