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 1KWCYR-0004UL-Qf for garchives@archives.gentoo.org; Thu, 21 Aug 2008 15:58:32 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D06D6E03A5; Thu, 21 Aug 2008 15:58:30 +0000 (UTC) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by pigeon.gentoo.org (Postfix) with ESMTP id 7F79EE03A5 for ; Thu, 21 Aug 2008 15:58:30 +0000 (UTC) Received: by ug-out-1314.google.com with SMTP id o4so24549uge.39 for ; Thu, 21 Aug 2008 08:58:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=su8zHOIXkjLk05JFEnqVqAnLl39VAK4oDfok4mZI3KM=; b=R5187rgGHa1qN07niyrWBPVS2j9J2UiJMV9LSCCAbBVtiViY9GldqD5UIRfYmC9dAC HnyhhFM/8KJ3Ig7z4T3m+RxgKkyOpjGfrLMwXsGLk1br1/DqNw/oQxCElu/ZvWzKgdkA B2LKIAGQoLUy7pOnxi5Aceldi5EXLcAESIN6c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=LFp4IBiax4OsCCUgI/8BGAzozxdIt7QtC1ABCJecbLiRja40FCUw2eFRwxJrUSh4/r rpPUosioyaMkVPKWWmMDC+/kP6tJf6Rwi0f8iVb3kUmRj2KWD4ctsJJ23JzRL8vl50Hc L7ZtJmV6oW9KuhSbQ693cGOvkm/sCM4xVPJmI= Received: by 10.66.250.17 with SMTP id x17mr1555984ugh.0.1219334309260; Thu, 21 Aug 2008 08:58:29 -0700 (PDT) Received: from localhost ( [92.235.187.79]) by mx.google.com with ESMTPS id m1sm6107781uge.17.2008.08.21.08.58.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 21 Aug 2008 08:58:28 -0700 (PDT) Date: Thu, 21 Aug 2008 16:58:18 +0100 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Re: Re: [RFC] What features should be included in EAPI 2? Message-ID: <20080821165818.38a3a7ad@googlemail.com> In-Reply-To: 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> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; x86_64-pc-linux-gnu) 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: multipart/signed; boundary="Sig_/FkDMQVhKEwxf5c+kza7ugK9"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: 0ced3104-3882-429b-a1d2-00b14fb9a3c0 X-Archives-Hash: 2e45d1bcb46f5959932aa58f3b41f233 --Sig_/FkDMQVhKEwxf5c+kza7ugK9 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 21 Aug 2008 16:35:18 +0100 Steve Long wrote: > Hmm fun as it isn't playing these games with you.. What? Deliberately arguing against an idea because it comes from the wrong people, even though they're the only ones with the practical experience on the issue? > > 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. Are you saying it is entirely up to him or that it should be entirely up to him? > >> Yeah I've always seen src_unpack as being more cogent to > >> preparation of src files, than to actually untarring stuff. > >=20 > > 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.=20 It's about making the ebuild language fit what most ebuilds do. > > 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. This one's a developer-targeted feature. The benefit to users is that a) developers have a nicer package format to work with, and b) when they want to add patches to an ebuild locally, they don't have to know how to reimplement src_unpack correctly. > > (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.. And all of those are complicated features that can't be delivered with ten minutes work, which would mean delaying EAPI 2. > > 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.=20 You misunderstand, again. Exheres has two improvements on default functions: the default_*/default mechanism, and better default_ implementations. Portage is taking only the former for EAPI 2. > In any event, it wouldn't be needed. Sure. You can do away with all the helpers and all the default functions in a future EAPI if you want. But all that'd do is make writing correct ebuilds much more tedious. Or, you can go the other way, as Exheres has, and improve the current lot of defaults to make writing ebuilds even easier. > 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. Neither src_configure nor src_prepare makes much difference to live ebuilds. > 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. Uhm. I think you're completely misunderstanding src_prepare. Go back and read the original email. If that's not clear enough for you, also have a look at how it's being used in Exherbo -- you can see plenty of practical examples. Then, once you've done so, please explain how the added simplicity and clarity is not a benefit. --=20 Ciaran McCreesh --Sig_/FkDMQVhKEwxf5c+kza7ugK9 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkitkJ0ACgkQ96zL6DUtXhFjSACgiX3Qo2cdm49hLKV9yi9YpZG2 kAwAn1YwTM9JoNsuKktLTmkEat0rl1Lm =UV7x -----END PGP SIGNATURE----- --Sig_/FkDMQVhKEwxf5c+kza7ugK9--