From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1J5xyG-0001C2-V3 for garchives@archives.gentoo.org; Sat, 22 Dec 2007 06:36:29 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.2/8.14.0) with SMTP id lBM6ZXbi018698; Sat, 22 Dec 2007 06:35:33 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by robin.gentoo.org (8.14.2/8.14.0) with ESMTP id lBM6XTuZ016155 for ; Sat, 22 Dec 2007 06:33:32 GMT Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 833DF64BD0 for ; Sat, 22 Dec 2007 06:33:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -0.095 X-Spam-Level: X-Spam-Status: No, score=-0.095 required=5.5 tests=[AWL=0.437, BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMWjX4qRAC4a for ; Sat, 22 Dec 2007 06:33:24 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 3E29664870 for ; Sat, 22 Dec 2007 06:33:23 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J5xuM-0003ro-Ds for gentoo-dev@gentoo.org; Sat, 22 Dec 2007 06:32:26 +0000 Received: from 91.84.103.179 ([91.84.103.179]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 22 Dec 2007 06:32:26 +0000 Received: from slong by 91.84.103.179 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 22 Dec 2007 06:32:26 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steve Long Subject: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) Date: Sat, 22 Dec 2007 06:35:07 +0000 Message-ID: References: <200712172320.01988.peper@gentoo.org> <20071218001855.78c1864c@blueyonder.co.uk> <20071218013651.58f4f565@eusebe> <200712180201.25872.bo.andresen@zlin.dk> <20071218220852.3f34edae@eusebe> <20071219000917.716749ee@blueyonder.co.uk> <20071219081224.15bf437f@eusebe> <20071219103208.1a077a96@blueyonder.co.uk> <20071220064644.60aa9572@eusebe> <20071220055318.53cd78a0@blueyonder.co.uk> <20071220140840.247b7763@eusebe> <1198166274.9302.95.camel@sapc154> <20071221003448.01402131@blueyonder.co.uk> <476BC30F.6060004@thefreemanclan.net> <20071221135922.3781ecdd@blueyonder.co.uk> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 91.84.103.179 User-Agent: KNode/0.10.4 Sender: news X-Archives-Salt: 57c6297b-68c3-4bbc-b0ef-5982ef5c6344 X-Archives-Hash: 81c0c2c439441e47d07f652094ddddef Duncan wrote: > our users -- Gentoo sysadmins by another name. THANK YOU! Finally someone said it (and explained it better than I could.) All our users-- the ones who deal with the glitches that can arise in a source distro which binary users never see-- have the skill level of an admin anywhere else. It might take someone two or three months to get the basics on Gentoo, but if you can manage a manual install and maintain a Gentoo box, no-one should be sneering at you (especially as they started out knowing nothing too.) > Without that clearly stated, I was conflating the two > possible changes, the one given by the GLEP, and the one left unspec-ed, > and thus reserved for the future and/or other non-Gentoo usage, > extensions /other/ than .ebuild[-]. > Interesting: it brings up the possibility of simply using another extension for files with eapi encoded in the name, and leaving the existing .ebuild to continue as is. PMs which don't support versioning would ignore them, since they're not .ebuild, and existing tools would need the same changes as with .ebuild-foo; .eapi-foo ? > Given the conflation, I was then left confused by the GLEP requirement > that the EAPI not be changed from that found in the filename (with the > filename EAPI defaulting to 0 if not given), set against the argument > that EAPI could then at some point be made dynamic, or otherwise less > firmly specified than filename semantics requires. But this would have to be based on /some/ sort of eapi suffix in the filename, or the file would be sourced by current (not future) versions of portage (the reason for changing the suffix in the first place.) Given that why not just use the same in the ebuild EAPI="foo" declaration, with the proviso that it's restricted to only appearing once in the file? Still seems much cleaner to me. Oh yeah, we have to do this *now* we can't wait 6 months or so, because there are tons of apps that our users need, which they can't get without ebuilds using an api which can't be sourced. This is supposed to be about the longer-term, not rushing through changes: it won't exactly take long to get a version of portage that doesn't automatically source ebuild files: it can just take the first EAPI line it finds and not source anything it doesn't know about. As ever the maintainer takes ultimate responsibility for ensuring their ebuild works, and the QA tool can trivially confirm that there's only one EAPI declaration. eg, this finds all ebuilds which have more than one SLOT declaration: find /usr/portage -type f -name '*.ebuild' -exec bash -c 'for f; do c=$(grep -c "\bSLOT=" "$f"); ((c>1)) && grep -H SLOT "$f"; done' _ {} + [all one line] It's not foolproof (gives false positives eg comments) so I'd use that other regex for EAPI and put some faith in the maintainers (and the commit-reviews.) Oh yeah I forgot, McCreesh thinks they're all idiots[1], so let's just do what he says. Funny thing is I think the USE-flag metadata thing would have breezed through as a GLEP; I don't recall one person saying they thought it was a bad idea. [1] http://lab.obsethryl.eu/content/paludis-gentoo-and-ciaran-mccreesh-uncensored -- gentoo-dev@gentoo.org mailing list