Re: [gentoo-dev] EBUILD_FORMAT support

[Paul de Vrieze]

On Tuesday 23 August 2005 18:00, Brian Harring wrote:
> On Tue, Aug 23, 2005 at 03:20:16PM +0200, Paul de Vrieze wrote:
> > To allow for this to work with current portage versions, perhaps it
> > would be an option to introduce a new extension for .ebuild scripts
> > that use it's functionality. That would allow all non-EAPI aware
> > portage versions to automatically ignore ebuilds that use this.
>
> not much for .ebuild? in the tree, personally.
> Why?  Cause portage *should not* ignore those ebuilds.  If the user
> wants to merge something that is a later ebuild api then they have, at
> least portage chucks an exception that the UI can wrap into "upgrade
> portage".
>
> With what you're proposing, we instead get bugs about portage missing
> packages.

What I mean is compatibility with current portage versions. Current 
versions do not understand EAPI. There would be a good chance that they 
could choke on packages with all kinds of new features, even in the sync 
phase. A different extension would ensure that those portage versions 
would still work (crippled) on a new tree. Of course such an extension 
change should only be done once. Once the API versions are available this 
is not an issue.

>
> > ps. I would also suggest requiring that EAPI can be retrieved by a
> > simple line by line parsing without using bash. (This allows for
> > changing the parsing system)
>
> No, that's yanks EAPI setting away from eclasses.

If the eclasses follow similar rules that would be easilly parseable. 
(taking inherit ...) into account is easy as long as the inherit line is 
on one line of it's own. (unconditionally) These rules that would 
allready be followed out of style reasons would make various kinds of 
parsers able to parse them.

> Only time this would be required is if we move away from bash; if that
> occurs, then I'd think a new extension would be required.

It would allow to for example restrict the ebuild format such that initial 
parsing is not done by bash (but the files are still parseable by bash). 
If we perform changes I think it should be done right in the first place.

> As is, shifting the 'template' loaded for an ebuild can be done in
> ebd's init_environ easy enough, so no reason to add the extra
> restrictions/changes.

One of the issues of ebuilds is the cache/metadata stuff. Parsing an 
ebuild for basic information takes a lot of time. This can be done lots 
faster with a less featured parser (I've written one some day) that 
accepts 98% of all current ebuilds, just doesn't like dynamic features in 
the toplevel. Such a parser could be a python plugin and as such easy to 
use from python. However to ensure compatibility with a faster parser the 
EAPI variable should be there in a way that is a little more strict than 
the other variables. And such a restriction is in practice not a 
restriction.

The restriction I propose would be:
- If EAPI is defined in the ebuild it should be unconditional, on it's own
  line in the toplevel of the ebuild before any functions are defined.
  (preferably the first element after the comments and whitespace)

- If EAPI is not defined in the ebuild, but in an eclass, the inherit
  chain should be unconditional and direct. Further more in the eclass the
  above rules should be followed.

Please note that many of the conditions are allready true for current 
ebuilds, just portage can "handle" more.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@g.o
Homepage: http://www.devrieze.net