From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Lgf6h-0007PF-Vt for garchives@archives.gentoo.org; Mon, 09 Mar 2009 13:01:24 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 75DDDE0369; Mon, 9 Mar 2009 13:01:22 +0000 (UTC) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.248]) by pigeon.gentoo.org (Postfix) with ESMTP id 31C32E0383 for ; Mon, 9 Mar 2009 13:01:22 +0000 (UTC) Received: by rv-out-0708.google.com with SMTP id f25so1752691rvb.46 for ; Mon, 09 Mar 2009 06:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=bni5yQBbca7mRwCQHJWh1S3+DNVDjSP9hEW3+YXQX8M=; b=v+z7SejVZ4dczKR4MWrHCaoq6C4uDjDz6CP2Dry1nvYYWHxCU7gM4TZXIzWqGe6CVr Th9X9HjXhOdvbTvSqs4ADwPkoc2ndT6ays88vg/ZxeEyEZ29l4d9Ncwv1VRwZ65zSzHM eLgxbYwcbm/aLF09Z0+P+bmt5I2+Rt0O9so2o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=sz+VLmz6zzX/3L5VgoXlzku5kKNmNWuf8bAiY2PjYGuvOkPFP/jfrUCwt+W3OdX3y/ 2xRomCnzkQ8Y2tsZdgXiEMJ9Kow/XMCMRZgxTu+mPY49GhnKk3lRF9mk315XPBnmkK9t RgtWNyPIL5L0daIS5/jodctdamhOqA9buY9zA= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Sender: techgurufloyd@gmail.com Received: by 10.140.171.18 with SMTP id t18mr3061598rve.95.1236603681773; Mon, 09 Mar 2009 06:01:21 -0700 (PDT) In-Reply-To: <49A472E3.1010204@gentoo.org> References: <49A472E3.1010204@gentoo.org> Date: Mon, 9 Mar 2009 07:01:21 -0600 X-Google-Sender-Auth: cc3262ee14e56c45 Message-ID: <4afbebfe0903090601r5759177bt98639c0c3a61b894@mail.gmail.com> Subject: Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives From: Jacob Floyd To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 10e8c403-7146-4441-bf8a-377f3323da3a X-Archives-Hash: d84f2c8954a060961e6bb918ee79549c 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)