Re: [gentoo-portage-dev] PATCH: initial EAPI awareness
On Fri, Sep 02, 2005 at 10:53:05AM +0200, Paul de Vrieze wrote: > On Friday 02 September 2005 08:04, Brian Harring wrote: > > > > Like I've said, EAPI is ebuild specific. Ebuild is a format; eapi > > defines revisions of it, in my mind a minor revision of the ebuild 1 > > format. Any form of loss of backwards compatability *should* be a > > different format, .ebuild2 for all I care. > > The new proposed format loses backwards compatibility. If there is > backwards compatibility no new format or api version is needed. EAPI > should work on the python level, not only on the ebuild.sh level. The two are utterly intertwined. Doesn't matter if portage thinks it's eapi 1 or 2, what matters is if the ebuild*sh env *creates* an eapi 1 or 2 env for execution. Python side just behaves a bit differently, ebuild*sh is where all of the actual execution occurs (and varies dependant on eapi). > > Trying to use EAPI to allow for N different formats into one format is > > wrong from where I sit; you would need a container format for it, > > which ebuild wasn't designed for (nor is it easily extensible to be > > made so I posit). > > No it would state that the eclass is 100% compatible with both by the > formats overlapping and the ebuild not threading outside the overlapped > area. And how is this going to work when it's more then just a split of a func? I'm not saying it can't be done, I'm saying it *shouldn't* be done. It's begging for screwups; relying on portage to pick and choose between eapi levels for an ebuild's execution env dependant on an eclass *requires* the ebuild to be fully compatible to those eapis, same for the eclass author. That's not so easy to do, and will lead to a buttload of case tests of EAPI, which isn't going to improve the code (imo). People aren't going to do it, is my opinion. It's unnecessarily complex with minimal gain; the gain being decreased due to the inherent complexity of A) pulling this off in portage B) comprehending *exactly* what portage will do in each case C) the ebuild/eclass author not only managing to get usage of *one* eapi correct, getting potentially N eapi's correct. D) eclasses that inherit eclasses requiring the same eapi compatability checks E) within two bodies of code, devs keeping seperated in their mind the differences between each eapi, and *never* blurring them. Note I'm not pulling the "everyone else is ignorant" crap that popped up on -dev ml; I'm stating that writing to an api is manual work, and people will screw up on it, just the same as in writing the implementation of that api, *we* will screw up on it. Bugs per line, it's unavoidable. Not advocating that we dumb everything down, advocating we don't add something that (assuming we get it right in implementation) is one hell of a pandora's box from the standpoint of complex ebuilds combined with complex eclasses. That's also not even getting into the fact that what you're proposing, effectively greping EAPI from the file is A) helluva lot slower on regen B) trying to turn ebuilds into a container format. They're not a container format, nor should they be (kitchen sink shouldn't be included). C) core's more then capable of supporting seperated formats; the 'container' should be the repository, not jammed within the package data. D) It's a helluva lot easier, and less chance for screwup to just define a new format, use a new extension, and have the repository implementation use a different pkg format for that file. E) New, non eapi=1 style change with a different extension wouldn't even be *seen* by the noncompliant repositories. Helluva lot simpler. Not advocating we define a new format every day; I'm advocating that we define a format (v1), we do tweaks to it, and define a new *seperate* format when we need stuff that is beyond the keen of the existing format. Shifting away from declarative syntax, moving away from bash syntax, etc. If it isn't akin to our existing definition of an ebuild, it's not an ebuild and should *not* be jammed into the ebuild format. It's a new beast, and should be seperated. That's also ignoring the additional interaction of elibs thrown into the mix. If what you're suggesting is implemented, eclasses *and* ebuilds would be litered with if [ "$EAPI" == 2 ]; then eapi2 specific stuff elif [ "$EAPI" == 1]; then eapi1 specific stuff else general, all eapi stuff fi Note that the code above also has a nice hidden bug in it that's not obvious till you think about it; there is no way to predict at the time of the ebuilds writing that EAPI3 will work for the else block, yet logic structures of that sort *will* exist if you open up the N EAPI compatibility for an ebuild/eclass. Any bumping of the potential eapi's for an ebuild/eclass will expose it. That and I'd hope if it were ever implemented, devs would be using functions within the logic block; ev
Re: [gentoo-portage-dev] PATCH: initial EAPI awareness
On Friday 02 September 2005 08:04, Brian Harring wrote: > > Like I've said, EAPI is ebuild specific. Ebuild is a format; eapi > defines revisions of it, in my mind a minor revision of the ebuild 1 > format. Any form of loss of backwards compatability *should* be a > different format, .ebuild2 for all I care. The new proposed format loses backwards compatibility. If there is backwards compatibility no new format or api version is needed. EAPI should work on the python level, not only on the ebuild.sh level. > Trying to use EAPI to allow for N different formats into one format is > wrong from where I sit; you would need a container format for it, > which ebuild wasn't designed for (nor is it easily extensible to be > made so I posit). No it would state that the eclass is 100% compatible with both by the formats overlapping and the ebuild not threading outside the overlapped area. Take for an example many simple kde applications. Those use the kde eclass to do all the work and only contain a skeleton of variables themselves. These ebuilds are compatible with both the current as the proposed new API. When marked so, they could be used as EAPI=1 as soon as the kde eclass is ported to EAPI=1. Similarly many eclasses do not provide src_compile, and as such are compatible with both EAPI versions. > EAPI's original specification was for handling addition of new funcs, > different hooks in the ebuild; I prefer it remain as this. The core > rewrite is format agnostic, if a new format is defined (whether a > massively managled version of ebuild or flat out new), it's a seperate > format and should be handled via the core, not via ebuild specific > package handling. EAPI now is going to be used for the above. It can however with very little effort be made such that future ebuild format revisions are possible. Also don't be mistaken that splitting out configure and make stages do need support from the python part. > > There's no reason a repository can't hold multiple formats internally; > the capability is there, use that rather then trying to jam too much > into EAPI, imo at least. How would you suggest to do this then. The ebuilds/eclasses are completely the same except for their EAPI definition. They also have the same (file)name. And that is not counting the fact that two files containing the same is bad design as there will allways be an issue of one file being updated and the other not. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpvjqA2Lzlsg.pgp Description: PGP signature
Re: [gentoo-portage-dev] PATCH: initial EAPI awareness
On Friday 02 September 2005 07:27, Zac Medico wrote: > Paul de Vrieze wrote: > > On Wednesday 31 August 2005 14:57, Brian Harring wrote: > >> Re: tagging EAPI at the top of a file, infra would probably shoot me > >> for doing such- till a live, fully compatible and *roughly* > >> equivalent parser is available, portage would have to do a bit of > >> grepping, jacking up the regen times. > > > > If in cache EAPI can be gotten from the cache. If not, I don't think > > it matters where in the file EAPI occurs from the standpoint of > > getting it's value. The only thing would be that in the future a fast > > EAPI parser could be made that would just look at EAPI and get its > > version. I could easilly write you such a parser. > > It is impossible write a parser for an unconstrained and unknown format > that may exist in the future. If we put a constraint on the format, in > order to parse the EAPI, then we contradict our original goal (to > unconstrain the format). It would be possible to make these restrictions small. A workable restriction could be to put the EAPI statement in the front of the file only preceded by whitespace and comments. After the line with the EAPI statement anything could happen. Even a completely binary format could be used. But indeed no constraints is impossible, so putting the format statement in the start of the file is the best solution. Besides the fact that it makes detecting the format that much faster, and allows bailing out before parsing the whole file if an unsupported api is detected. > A better approach IMO would be to store the EAPI in a separate file > such as metadata.xml. This would allow *absolute* flexibility in the > "ebuild" format. Portage would be able to select an appropriate parser > with no need to examine the "ebuild" itself. Please don't. Parsing xml is a lot harder than recognizing lines. A simple EAPI parser would probably use canned (library) line reading functions and then look if the line starts with "EAPI=". If so it reads the EAPI, else it checks the next line. No need to understand anything else of the file format. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp3kuxMM0HR2.pgp Description: PGP signature
