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: [EMAIL PROTECTED] Homepage: http://www.devrieze.net
pgpLXOBvmQbRj.pgp
Description: PGP signature
