| 1 |
On Tue, 13 Nov 2007 12:22:03 -0800 |
| 2 |
Chris Gianelloni <wolf31o2@g.o> wrote: |
| 3 |
> Any chance we can *at least* wait until we have a release out the door |
| 4 |
> that has a portage version which supports these features *before* we |
| 5 |
> start trying to use them in the tree? Our general rule was to not use |
| 6 |
> features for 1+ years since it was added to a *stable* portage before |
| 7 |
> we started using them. |
| 8 |
|
| 9 |
That was only the case because previously, using new features that |
| 10 |
Portage didn't support would cause horrible breakage. Now, instead, the |
| 11 |
ebuilds show up as being masked. |
| 12 |
|
| 13 |
> Now, this isn't so much of an issue with individual ebuilds, but |
| 14 |
> you're talking about changing how the Java eclasses work, essentially |
| 15 |
> blocking *anyone* using an older portage (including everyone |
| 16 |
> installing from 2007.0 media) from using any package which inherits |
| 17 |
> the eclass. |
| 18 |
|
| 19 |
They just need to upgrade their package manager first. Easy. |
| 20 |
|
| 21 |
> Also, we should really think about this sort of thing before we start |
| 22 |
> using it. How are we going to support EAPI changes in eclasses? What |
| 23 |
> if I have an eclass with EAPI=1 features and I want to add some EAPI=2 |
| 24 |
> features? I think allowing EAPI=* globally in an eclass should be |
| 25 |
> prohibited, unless the *entire* eclass is planned for EAPI=* ebuilds, |
| 26 |
> only. |
| 27 |
|
| 28 |
Doing an entire eclass for one specific EAPI generally isn't a good idea |
| 29 |
since it's fairly likely that EAPI bumps will be a fairly common thing. |
| 30 |
|
| 31 |
> In other words, you'd need new EAPI=1 eclasses for your EAPI=1 |
| 32 |
> ebuilds. Either that, or some way to say something like: "execute |
| 33 |
> code path A for EAPI=0 and execute code path B for EAPI=1" or |
| 34 |
> something similar. I would suspect that the "best" current solution |
| 35 |
> is to check EAPI in the individual functions and perform the right |
| 36 |
> actions based on those functions, rather than marking an entire |
| 37 |
> eclass. After all, only EAPI=* functions need to be "hidden" behind |
| 38 |
> EAPI. |
| 39 |
|
| 40 |
A solution with EAPI-agnostic code in foo-common.eclass and |
| 41 |
EAPI-specific code in foo.eclass, foo-eapi1.eclass etc is probably more |
| 42 |
readable and maintainable in most cases. |
| 43 |
|
| 44 |
-- |
| 45 |
Ciaran McCreesh |
Archives