| 1 |
Zac Medico wrote: |
| 2 |
> If we implement the repo-level profile, it can have a |
| 3 |
> bashrc (much like profile.bashrc) that acts as a repo-level ebuild template |
| 4 |
> (like install-helpers.eclass). Actually, the repo-level profile already exists |
| 5 |
> in the form of files such as ${PORTDIR}/profiles/{package.mask,arch.list}, |
| 6 |
> though it doesn't yet have support for a bashrc (ebuild template). |
| 7 |
|
| 8 |
Well, this is a nice idea, but not applicable to this problem. I had a |
| 9 |
chat with Brian some days back, and the conclusion was that factoring |
| 10 |
out the helper functions is basically an EAPI change. If we handle it |
| 11 |
transparently, as in either using PORTAGE_AUTOLOAD_ECLASS or the |
| 12 |
repo-level profile, we move parts of the EAPI out into the tree, which |
| 13 |
is a bad idea because we are unable to support multiple versions. As the |
| 14 |
EAPI needed for the ebuild is unknown when sourcing |
| 15 |
install-helpers.eclass, we're actually forced into using that one and |
| 16 |
only version, which is quite limiting. |
| 17 |
|
| 18 |
So, the correct way to do it is to define an EAPI=1 that does no longer |
| 19 |
include these helper functions and make the eclasses/ebuilds that use it |
| 20 |
inherit the eclass manually. However, this will need to run through -dev |
| 21 |
and I'm afraid the ebuild devs wouldn't like it at all :-/ |
| 22 |
|
| 23 |
-- |
| 24 |
Kind Regards, |
| 25 |
|
| 26 |
Simon Stelling |
| 27 |
Gentoo/AMD64 developer |
| 28 |
-- |
| 29 |
gentoo-portage-dev@g.o mailing list |
Archives