On Mon, 26 Sep 2016 21:35:29 +0100 James Le Cuirot <ch...@gentoo.org> wrote: [...] > > 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?
Well, I don't see any fundamental difference in specing 'call this utility' vs. proper profile.bashrc. If you don't want specing, then indeed an utility is the way to go, but this could imply some packages build with portage because it elibtoolizes them and fail with PMs that don't. Also, keep in mind that with an external utility you have far less control on what is executed than with something in $PORTDIR: people may use an older buggy version of the utility, while when shipping it in $PORTDIR you are sure that the version is up to date.
