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 1L5mmb-0005qw-9c for garchives@archives.gentoo.org; Thu, 27 Nov 2008 19:44:13 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 01EC0E027D; Thu, 27 Nov 2008 19:44:11 +0000 (UTC) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by pigeon.gentoo.org (Postfix) with ESMTP id 98425E027D for ; Thu, 27 Nov 2008 19:44:10 +0000 (UTC) Received: by ug-out-1314.google.com with SMTP id 30so1751891ugs.39 for ; Thu, 27 Nov 2008 11:44:10 -0800 (PST) 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:x-mailer:mime-version:content-type; bh=ot3htEKxMU/SJIJvHTOAi3+E0yIHE8Js7oialkrMLg8=; b=eZRcvN1VmumsF05d2ImUSu4u71EtnJt7/RsYC+5k4mqqulyvjCkaTk3Lopgz0EQvu/ BWLTLCpiH5htON4AXNFzbyatGAdupAe6cJLiAnJWys+cUCKhzSqkqf4wpKvsNbLxcrKz l9ZVn4wLMqkW29xZPnuJMsUJSghWn+9nsXiT0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:x-mailer:mime-version:content-type; b=v7XA9vI5NBDM/SIuSBB4YFERhnsbA2HAgl1IO+6edR6vDgTlxhNbEH/QVIXQhB3dmF k2hXuNpZTNwSeJj1z5BIb12k+N82iqUVHrrKaOp6txsTLWCwIe45anaksVkEuMDBgBoV X0Ci1BVfYppMelyP+cVfunskqAaDzBLBMBjtE= Received: by 10.67.115.2 with SMTP id s2mr501226ugm.62.1227815049857; Thu, 27 Nov 2008 11:44:09 -0800 (PST) Received: from snowmobile (92-235-187-79.cable.ubr18.edin.blueyonder.co.uk [92.235.187.79]) by mx.google.com with ESMTPS id l4sm201446ugf.2.2008.11.27.11.44.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 27 Nov 2008 11:44:09 -0800 (PST) Date: Thu, 27 Nov 2008 19:43:59 +0000 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] RFC: DEFINED_PHASES magic metadata variable Message-ID: <20081127194359.05327003@snowmobile> X-Mailer: Claws Mail 3.6.1 (GTK+ 2.14.4; i686-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_/dlSOw9wuaQ=Hchs.1_dlzAN"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: 2b1e866b-e327-4314-b175-a32ca04b8b32 X-Archives-Hash: 8c34d8efbc0d31ab28c517403dc83f62 --Sig_/dlSOw9wuaQ=Hchs.1_dlzAN Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I'd like to propose a new metadata variable called DEFINED_PHASES. Like INHERITED, it will be generated by the package manager rather than by a combination of explicit ebuild and eclass variables. The DEFINED_PHASES variable is for package manager use; it may or may not be exported to the ebuild, and must not be used or set in any way by ebuilds. The DEFINED_PHASES proposal has (almost -- see below) no developer-visible effects, other than reserving a variable name. The name DEFINED_PHASES is currently only for convenience, since the metadata cache format uses fixed positions rather than a key=3Dvalue format, but this may change in the future. In flat metadata cache, DEFINED_PHASES shall be line 17. The DEFINED_PHASES variable will contain a space separated arbitrarily ordered list of phase names. A phase name is listed in DEFINED_PHASES if and only if the ebuild or an eclass used by that ebuild provides an implementation of that phase's phase function. For example, the current value for app-editors/vim-7.2.021 would be (possibly not in this order): DEFINED_PHASES=3D"setup unpack compile install test postinst postrm" If an ebuild uses the defaults for every single phase, rather than defining a blank DEFINED_PHASES, the package manager shall set it to the string "-". This will let the package manager tell the difference between "this metadata was generated by an old package manager" and "this ebuild uses defaults for everything". Support for DEFINED_PHASES shall be optionally retroactively added to all existing EAPIs. Package managers are not required to generate it, and package managers may not assume its existence. Future EAPIs may make DEFINED_PHASES mandatory. Having DEFINED_PHASES upfront is useful in a number of ways to the package manager: * It lets the package manager avoid having to run phases that have a "do nothing" default and that aren't defined by the ebuild. This is currently a fairly minor issue, but in the future if we start using src_fetch_extra (bug 249086) or pkg_pretend it makes quite a bit of difference. * It lets the package manager parallelise pkg_* functions in many situations. * It lets the package manager avoid having to go to 'interactive' mode for every phase of PROPERTIES=3Dinteractive ebuilds. There is one subtle implication of this proposal: it means the phases defined by an ebuild must now be metadata-invariant. So the following is remains legal: if [[ ${EAPI} =3D=3D 2 ]] ; then src_configure() { blah } fi But this goes from being "probably illegal, but might work by fluke" to "definitely illegal": if use foo ; then src_configure() { blah } fi This is of course a good thing. --=20 Ciaran McCreesh --Sig_/dlSOw9wuaQ=Hchs.1_dlzAN Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkku+IQACgkQ96zL6DUtXhG0MACg0eMza66+2RaAXPZNquhTZQU+ hegAoKA8gs8IbYncJk2Q9f7a4Lc18p2i =bhQH -----END PGP SIGNATURE----- --Sig_/dlSOw9wuaQ=Hchs.1_dlzAN--