From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1KWCFF-0003Af-0A for garchives@archives.gentoo.org; Thu, 21 Aug 2008 15:38:41 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1A305E0351; Thu, 21 Aug 2008 15:38:40 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id BAF48E0351 for ; Thu, 21 Aug 2008 15:38:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id EDA39667D0 for ; Thu, 21 Aug 2008 15:38:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -0.569 X-Spam-Level: X-Spam-Status: No, score=-0.569 required=5.5 tests=[AWL=0.963, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 QVoYzEcn4dFj for ; Thu, 21 Aug 2008 15:38:32 +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 2260266BBC for ; Thu, 21 Aug 2008 15:38:31 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KWCEx-0007wv-Jq for gentoo-dev@gentoo.org; Thu, 21 Aug 2008 15:38:23 +0000 Received: from 82.153.77.250 ([82.153.77.250]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Aug 2008 15:38:23 +0000 Received: from slong by 82.153.77.250 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Aug 2008 15:38:23 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steve Long Subject: [gentoo-dev] Re: Re: Re: [RFC] What features should be included in EAPI 2? Date: Thu, 21 Aug 2008 16:35:18 +0100 Message-ID: References: <48A298D9.3030402@gentoo.org> <20080813130329.0fe55b90@googlemail.com> <82dd739f0808190545u3cb1632fj3590a6b130dd304a@mail.gmail.com> <48AB0A6D.6050705@gentoo.org> <20080819191804.19c67b0a@googlemail.com> <20080819214353.1fd55c04@googlemail.com> 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 82.153.77.250 User-Agent: KNode/0.10.9 Sender: news X-Archives-Salt: 7a31dc0f-aa15-491a-9cfe-3a23a24439a6 X-Archives-Hash: 3e64ff873ebd9fbbd696791f0850a8b7 Ciaran McCreesh wrote: > On Tue, 19 Aug 2008 21:27:03 +0100 > Steve Long wrote: >> > On Tue, 19 Aug 2008 23:31:17 +0530 >> > Arun Raghavan wrote: >> >> Ciaran McCreesh wrote: >> >> > The benefit is that it's a logically separate action, and will >> >> > avoid all the silliness of people repeatedly changing their >> >> > minds about which phase should do the eautoreconf calls and so >> >> > on. >> Er, that would be the new src_configure? > > Oh really? > Hmm fun as it isn't playing these games with you.. >> > In the grand scheme of things, no. In the grand scheme of things, >> > you only *need* a single src_ function. From a maintainer >> > convenience perspective, however, src_prepare is marginally more >> > useful than having a split src_configure. >> > >> How so? >> >> From a user point of view, and from a maintenance point of view, >> src_configure is very useful. > > Any reason you can provide for src_configure being useful can be used > with slight modification for src_prepare. > Which is no reason to add a new phase. OFC if zac wants to provide it that's entirely up to him. >> > It's a better mapping of the things ebuilds do than the current set >> > of functions. >> > >> > The logic is this: lots of ebuilds end up duplicating src_unpack >> > (or, in future EAPIs, calling 'default') and then adding things to >> > do preparation work. Experience suggests that the most common >> > reason for overriding src_unpack is to do preparation work, not to >> > change how things are unpacked. >> > >> Yeah I've always seen src_unpack as being more cogent to preparation >> of src files, than to actually untarring stuff. > > Yes, the 'unpack' in the name really does go along with the phase being > used to prepare things. > Oh so this is about correct nomenclature rather than anything else? I see. >> So what? Why make a new phase which every new dev has to know about, >> and we have to provide pre_ and post_ hooks for, when the existing >> phase covers the usage fine? > > Make a phase for each common logically distinct operation. Which, with > src_prepare being added, we almost have. > Yes, I see, because it's really needed; real functionality our users have been crying out for. > (The one missing is a src_fetch_extra or somesuch, for use by the scm > eclasses. But that wants special handling, and is probably best left to > another EAPI...) > Yes, a defined, configurable API for dealing with any version control would be useful, though your minion seemed to argue against it in #-portage. I can think of a couple of things that would be more useful to end-users: pkg_check for interactive ebuilds (eg license acceptance or media access), proper support for cross-compiling, integration of prefix, better handling of overlays, and of binpkgs.. >> > (Number-wise... For Exherbo, where the split's already been made, >> > custom src_prepare functions are three times more common than custom >> > src_unpack functions. And that figure's significantly lower than >> > what Gentoo would see, because with exheres-0 'default' functions >> > you don't need to write a src_prepare if you're merely applying >> > patches.) >> > >> Well it's easy enough to auto-apply patches, given a declaration in >> the ebuild (since files for all versions are in the same dir.) It >> certainly doesn't need a new phase. > > Well, if you're proposing that Gentoo also adopts the more complicated > default_* functions from exheres-0, you're more than welcome to write > up a proposal... > Tsk of course not. default functions are in the pipeline in any case, but glad to see you're still using this list for proselytising your pet project while avoiding true discussion. In any event, it wouldn't be needed. >> >> The *only* potential "benefit" I see here is that at some point of >> >> time in the nebulous future, it might be possible to tell the PM to >> >> always skip src_prepare in order to give a system where everything >> >> is "vanilla". >> > >> > Such a system wouldn't be usable... Not all of Gentoo's patches are >> > non-essential. >> > >> So the real, fully-defined, explicit benefit is.. > > The same as the benefit of splitting src_compile into src_configure and > src_compile, except that it'll be of use to a slightly larger > proportion of ebuilds. > As ever, you fail to argue the actual case, preferring to hide behind "the same reasons as.." which is a variant on the "if you don't understand some one line comment, you're not qualified to discuss anything (plus you're ugly.)" The reasoning others have given (yes it is possible to explain why without making people read thru 20 one line emails) is that this would be useful for live ebuilds. In maintenance terms (when looking at the lifecycle of an ebuild) I don't see the need, since there is no unpacking required from a vcs pull. Once it's made into a normal ebuild, any preparation would necessarily require review and might not be needed at all. Call the function what you like (or add a new phase with the hooks) it's still logically one point in time. For a live ebuild it's to prepare the src, for a normal one to (possibly) unpack and prepare. src_configure is a logically distinct action which warrants a new phase, since the e*conf call in compile makes retrying a long build (without having to recompile stuff which doesn't need it) much more difficult; its absence prevents full use of make. Prepare does not warrant a new phase imo since it should only be run once per compilation instance; anything it does can either be done in unpack, or in configure should that be more useful.