Hello all,
Here are my comments, opinions, and a recommendation regarding "GLEP
55" and similar proposals. I've put in 1) A) and a) numbering to
differentiate the various lists. Though perhaps long winded, at least
check out the Recommendation below.
The idea of sticking EAPI in metadata.xml was opposed because of XML
overhead, and it's a general purpose file, whereas this would force it
to have versioned info. Makes sense to me. Though that was one of the
ideas I was toying with because the EAPI really is metadata.
===== Extension =====
I don't like the idea of changing the extension because (in part
summarizing what some others have said):
1) inconsistency is not good (rh/fedora has always been .rpm, debian
has had .deb, gentoo has .ebuild) That's also why we prefer tabs over
spaces and ordering the variables uniformly (at least on sunrise).
It's a consistency issue.
2) If you change the extension, it becomes technically more difficult
to prevent multiple versions of the same package, thus users probably
will be required to start specifieing an EAPI when they want to merge
a package, because several devs, perhaps on overlays, will start
providing multiple versions of ebuilds in different EAPI.
3) #2 brings GLSA into play - Changes may have to be made in packages
implementing a variety of eapis creating a greater burden to see what
the difference is between these different ebuilds.
4) If portage does enforce the single eapi per version, that creates
an even bigger problem for other "package managers" which was a
problem that this GLEP was trying to address, but ends up making
smooth interop even more difficult. Some PMS will support multiple
EAPIs and others will say no... Overlays...
5) Version bumps are more difficult as you have to worry about the
eapi in the file name
6) If GLEP 55 goes in without GLEP 60, you may need to add a new key
in the Manifest for each new EAPI: EBUILD-1 EBUILD-2 EAPI-2-EBUILD...
(or something like that) As it is it's just EBUILD. If/when GLEP 60
goes in as well, then you have the issue of, "we changed the name -
it's no longer an ebuild, but the manifest says it is" which might be
a tad confusing (and inconsistent)
===== In Ebuild =====
The idea of leaving EAPI defined in the ebuild has the following setbacks:
A) sourcing the ebuild to discover the EAPI enforces a strict global
part, which prevents significant changes to inherit amongst other
things
B) It could break as we migrate to newer versions of bash or perhaps
"ebuilds" or equivalents that might be in another language (who knows)
C) Having a spot locked down in an ebuild to search for EAPI brings a
migration drawback, as current ebuilds have something else on line 4
or line 5 or whatever, and a potentially erroneous value could be
returned for EAPI
D) Sourcing the ebuild twice brings a lot of overhead significantly
slowing an already (many times) slow process (especially when you
imagine KDE and other packages that take a while to compile - 6
seconds extra for each package - *shiver*). And it's ugly to have to
do it twice.
E) EAPI really is metadata and doesn't should be accessible before
sourcing the ebuild.
===== Recommendation =====
OK. Now for a slightly different solution, or a twist on the other
solutions if you will:
Stick EAPI info in the Manifest. The Manifest stores metadata info
about the ebuilds for security and validation purposes, why not add a
string that determines which eapi to use? This then would be generated
every time someone did an "ebuild foo-1.0.ebuild digest". To specify
the eapi version, the developer would specify, as is now, EAPI="bla"
in his ebuild, and grep or similar would be used to extract this when
the digest is created. The above mentioned points compare with this
solution (as I see it) as follows:
-1) Preserves .ebuild allowing for changes if a move were ever made to
some other format (who knows: python, or
some-cool-new-script-that-beats-bash-by-a-long-shot)
-2) Does not change the extension
-3) Ditto
-4) Ditto
-5) Version bumps might take a fractoin longer, as an additional grep
is added to the digest process... but arch maintainers shouldn't have
a problem with that. (I'm not an arch maintainer, mind you. I'm not
even @g.o)
-6) This takes care of any Manifest issue, because eapi'll be defined
to start off with in the Manifest in a uniform manner
-A) No need to source the ebuild twice, just grab the variable from
the manifest in the normal execution of digest verification. However
if the digest is wrong, or the Manifest doesn't exist or whatever,
that is an error and error handling will need to be introduced to grep
the EAPI at this point if regenerating the digest is needed/requested
-B) A new EAPI would be introduced for such "new" versions of bash and
if there were other formats (as in, not bash) they really should get
their own extension anyway, but we need some uniform way to grep it
and grab the info, or if it can't be found assume that it's EAPI 0
-C) It wouldn't have to be on a specific line, though no logic could
be used to determine the EAPI (eg no: if use bla; then EAPI="bla"; fi)
But it's not used that way right now anyway.
-D) This removes the overhead issues of leaving it in the ebuild.
-E) The dev specifies it in their ebuild, but it's put in the Manifest
where metadata about ebuilds belongs.
Now, as far as mitigating migration issues with old PMS that want to
use the old inherit, let them =) :
### Imaginary ebuild snippet ###
EAPI="NewFoo"
inherit eapi
inherit2 eutils mypkg.local whatever
new_func() {
#and other stuff that isn't in eapi 0-2 only in the fancy
"NewFoo" EAPI I just invented.
if pig and oink; then ewarn "You're in a barnyard, watch your
step! If flames went up, this list wouldn't like it."; fi
}
new_func pig oink
### Imaginary ebuild snippet ###
===== Explanation =====
Create a new eapi.eclass that smoothes migration.
a) You can have it eerror or ewarn or something to let the user know
they need to upgrade to a new version of portage, or file a bug report
with their PMS to support the new EAPI ${EAPI} that is used by this
package.
b) Such an eclass can implement a bogus inherit2 which would allow
older PMS to at least sort of finish sourcing the ebuild.
c) it could die gracefully on known problematic PMS (yes, a die in the
global scope - but it would be the one exception in the entire portage
tree - ebuilds still would not be allowed to put die in the global
scope, and pre-"inherit eapi" (not pre-inherit2) lines in the ebuild
would still have to conform to EAPI 0 specs, but everything after that
point would be the new eapi spec.
d) It's a graceful stop-gap to help relieve stress due to users not
upgrading in 2 or 3 years or whatever might happen, it'll give them a
smoother upgrade path.
e) at some point when it's determined that users don't need such an
eclass anymore, nearly everyone has upgraded or whatever, the eclass
could be changed/removed/whatever/I don't know. But until such a
point, would include placeholder functions for new "functions"
unimplemented in older PMS.
f) if an eapi implements features in the global scope that are
drastically different from one eapi to the other, the function could
simply put a DEPEND on the newer portage version, and display a
message that portage will be updated and then they'll need to
re-emerge the package, or something like that.
inherit2 would be a new fangled inherit can do whatever you want, and
would be an dev-opt in type thing, the original inherit could, in
theory, be used to inherit other eclasses, but those eclasses would
also be restricted to EAPI 0 (or EAPI 1, 2 with proper "if [[ ${EAPI}"
sniffing) specs, wheras ebuilds in inherit2 would not have that
restriction and could use the newfangled features.
Anyway, there's my 2 cents. What do you all think?
Jacob Floyd
(on irc in some channels: techgurufloyd)
