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 1KVVmi-0000SF-8f for garchives@archives.gentoo.org; Tue, 19 Aug 2008 18:18:24 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 54E2BE01E3; Tue, 19 Aug 2008 18:18:23 +0000 (UTC) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by pigeon.gentoo.org (Postfix) with ESMTP id F0E6DE01E3 for ; Tue, 19 Aug 2008 18:18:22 +0000 (UTC) Received: by ug-out-1314.google.com with SMTP id o4so516808uge.39 for ; Tue, 19 Aug 2008 11:18:22 -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=2VFE9L3glSsoUYxEgCjs3aWM4Xny++l9OewsInIQOXc=; b=NFdZuT517jaH/AeGiQYce5JxOiPvm5S2O6oieGUfd45G6iJpqrg51vA3PvyVtgn67M oI/7vbWcg/pvYFRU64T+X2PBWRdHlMNAJm/MWAhMczxc88Oijl8C8YJjbAR8ANZZi7Yj Tjg7e2MNyVLJuO1yAWDdFULAPMjpBXBq5e7QM= 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=a6Ht552HLlLpuNvTLROx7CcZU5Vxm+zbFgzF5dqeBPIDMwzVkQ8fB1qPvljfvx97OC A3sX/9QlZCjHtcHSo9WCVZfO9ARHowilstydWOd61kNcyrwyoT7DNzIg28V9SjcN7zZS NGbjYwnt1M9vQKPADYqQ/zg2EXjbz/meBd0T0= Received: by 10.67.10.8 with SMTP id n8mr5348320ugi.23.1219169901065; Tue, 19 Aug 2008 11:18:21 -0700 (PDT) Received: from localhost ( [92.235.187.79]) by mx.google.com with ESMTPS id e33sm3270848ugd.81.2008.08.19.11.18.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 19 Aug 2008 11:18:19 -0700 (PDT) Date: Tue, 19 Aug 2008 19:18:04 +0100 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: [RFC] What features should be included in EAPI 2? Message-ID: <20080819191804.19c67b0a@googlemail.com> In-Reply-To: <48AB0A6D.6050705@gentoo.org> References: <48A298D9.3030402@gentoo.org> <20080813130329.0fe55b90@googlemail.com> <82dd739f0808190545u3cb1632fj3590a6b130dd304a@mail.gmail.com> <48AB0A6D.6050705@gentoo.org> 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_/QZCn7U=wMEDAU7jDaP+iejr"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: ae01b60a-0667-4140-8ca6-c6c2bf048dfa X-Archives-Hash: 9f6c5678073977dc1b59360e07de87ab --Sig_/QZCn7U=wMEDAU7jDaP+iejr Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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. >=20 > a) Is this really an issue for maintainers? It's not a huge issue, any more than src_configure is. Equally, it's not expensive to implement. > b) Does it really matter? 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. > c) So the flow will look like: >=20 > ... > src_unpack > src_prepare > src_configure > src_compile > ... >=20 > To me this seems like an unnecessary overgeneralisation. 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. (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.) > 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. --=20 Ciaran McCreesh --Sig_/QZCn7U=wMEDAU7jDaP+iejr Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkirDmIACgkQ96zL6DUtXhEw8wCguu5Wjs6H1br/TlTt9Lg14WD3 pd4AmgO+3qJuyWQ9HgG9eeIH3DblFEC5 =xatF -----END PGP SIGNATURE----- --Sig_/QZCn7U=wMEDAU7jDaP+iejr--