| 1 |
On Sun, 23 Sep 2012 13:30:41 +0200 |
| 2 |
Pacho Ramos <pacho@g.o> wrote: |
| 3 |
|
| 4 |
> El dom, 23-09-2012 a las 13:13 +0200, Michał Górny escribió: |
| 5 |
> > On Sun, 23 Sep 2012 13:03:56 +0200 |
| 6 |
> > Pacho Ramos <pacho@g.o> wrote: |
| 7 |
> > |
| 8 |
> > > That would be better as there are a ton of ebuilds not inheritting |
| 9 |
> > > autotools-utils.eclass even being autotools based (think for example in |
| 10 |
> > > gnome packages or many others) |
| 11 |
> > |
| 12 |
> > You could fix those ebuilds to inherit it too ;). autotools-utils was |
| 13 |
> > especially designed to use out-of-source builds for multilib |
| 14 |
> > in the future. |
| 15 |
> > |
| 16 |
> > I'm afraid the 'upper level' is technically impossible without either |
| 17 |
> > going into PM itself (which means waiting for EAPI 6 at least |
| 18 |
> > and getting some scary logic into it) or reinventing the phases alike |
| 19 |
> > ruby-ng/python-distutils-ng. Well, the latter may be useful to some |
| 20 |
> > degree; still, it would require each ebuild to redefine all phases. |
| 21 |
> > |
| 22 |
> |
| 23 |
> Then, I think that main blocker to use autotools-utils.eclass more |
| 24 |
> widely is that it needs at least eapi2, then, I am unsure if all |
| 25 |
> packages currently shipped in emul packages could bump their eapi due |
| 26 |
> compat with old systems. |
| 27 |
|
| 28 |
I doubt that is an important problem anymore, considering that portage |
| 29 |
requires at least EAPI 2 (and some ebuilds use EAPI 3 already). |
| 30 |
|
| 31 |
-- |
| 32 |
Best regards, |
| 33 |
Michał Górny |
Archives