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