| 1 |
On Tue, Aug 23, 2005 at 03:20:16PM +0200, Paul de Vrieze wrote: |
| 2 |
> To allow for this to work with current portage versions, perhaps it would |
| 3 |
> be an option to introduce a new extension for .ebuild scripts that use |
| 4 |
> it's functionality. That would allow all non-EAPI aware portage versions |
| 5 |
> to automatically ignore ebuilds that use this. |
| 6 |
not much for .ebuild? in the tree, personally. |
| 7 |
Why? Cause portage *should not* ignore those ebuilds. If the user |
| 8 |
wants to merge something that is a later ebuild api then they have, at |
| 9 |
least portage chucks an exception that the UI can wrap into "upgrade |
| 10 |
portage". |
| 11 |
|
| 12 |
With what you're proposing, we instead get bugs about portage missing |
| 13 |
packages. |
| 14 |
|
| 15 |
> ps. I would also suggest requiring that EAPI can be retrieved by a simple |
| 16 |
> line by line parsing without using bash. (This allows for changing the |
| 17 |
> parsing system) |
| 18 |
No, that's yanks EAPI setting away from eclasses. |
| 19 |
|
| 20 |
Only time this would be required is if we move away from bash; if that |
| 21 |
occurs, then I'd think a new extension would be required. |
| 22 |
|
| 23 |
As is, shifting the 'template' loaded for an ebuild can be done in |
| 24 |
ebd's init_environ easy enough, so no reason to add the extra |
| 25 |
restrictions/changes. |
| 26 |
|
| 27 |
My 2 cents, at least ;) |
| 28 |
~harring |
Archives