| 1 |
On Mon, 26 Sep 2016 21:35:29 +0100 |
| 2 |
James Le Cuirot <chewi@g.o> wrote: |
| 3 |
[...] |
| 4 |
> > On the other hand, we could go the complete opposite direction of |
| 5 |
> > what has been done in the past years with PMS: provide a generic |
| 6 |
> > way to extend ebuild env from profiles, with the ability to |
| 7 |
> > "include" some "eclasses", define default phases and pre/post |
| 8 |
> > phases hooks. This would have, e.g., saved the need to completely |
| 9 |
> > rewrite and spec epatch, avoided every PM to copy/paste default |
| 10 |
> > phases implementations from PMS, etc. However, this has somewhat |
| 11 |
> > the same disadvantage than eclasses: one commits crap there and |
| 12 |
> > breaks every system in subtle ways... |
| 13 |
> |
| 14 |
> I don't think I want to open this can of worms either. :( |
| 15 |
> |
| 16 |
> You said that flameeyes raised this about 10 years ago. It has indeed |
| 17 |
> been 10 years! |
| 18 |
> |
| 19 |
> https://archives.gentoo.org/gentoo-dev/message/caa153de0d23dc264330f5e702f26e58 |
| 20 |
> |
| 21 |
> The solution he preferred back then was to split elibtoolize into its |
| 22 |
> own package and have Portage depend on it. I hadn't considered that |
| 23 |
> and I quite like it too. There was only one brief reply to the thread |
| 24 |
> back then. Can you think of any downsides now? |
| 25 |
|
| 26 |
|
| 27 |
Well, I don't see any fundamental difference in specing 'call this |
| 28 |
utility' vs. proper profile.bashrc. If you don't want specing, then |
| 29 |
indeed an utility is the way to go, but this could imply some packages |
| 30 |
build with portage because it elibtoolizes them and fail with PMs that |
| 31 |
don't. |
| 32 |
|
| 33 |
Also, keep in mind that with an external utility you have far less |
| 34 |
control on what is executed than with something in $PORTDIR: people may |
| 35 |
use an older buggy version of the utility, while when shipping it in |
| 36 |
$PORTDIR you are sure that the version is up to date. |
Archives