From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1LjJig-0006Pc-E4 for garchives@archives.gentoo.org; Mon, 16 Mar 2009 20:47:34 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8C3D9E0484; Mon, 16 Mar 2009 20:47:33 +0000 (UTC) Received: from mail-ew0-f173.google.com (mail-ew0-f173.google.com [209.85.219.173]) by pigeon.gentoo.org (Postfix) with ESMTP id 1463EE0484; Mon, 16 Mar 2009 20:47:32 +0000 (UTC) Received: by ewy21 with SMTP id 21so3740534ewy.34 for ; Mon, 16 Mar 2009 13:47:32 -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:cc:subject :message-id:x-mailer:mime-version:content-type; bh=ofHjZNKvnPb6rXMRlwy+VrFhaWzzL4Wp8XoO+m5uxwA=; b=qL9FJEU0o0ncPgQlk8wTxudwgtQQOEzB5wdJ6xBTPSop0oU01q/ZNN6ZMmohayVHlN YmHoKuDZ0dvRl0bf616FPSRKSw57kAWXedx2TdHO6c1esixFqb/g539NaCW+U3xKn6fh vmMkkDAdC0UQNCiM97GyHQXlGTT/xFi1htlAg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:x-mailer:mime-version :content-type; b=NijJkfUNdzi2+nGRSxwCJlQ7bg4i1PQKvTd82dErvM/7DXlSlW8u4+SG2qI4zvjwV0 uRMRUj38+o3SXkHAw5lEBk5IgXzZQsMBXuQdLO/VA0LraEWbyPXhLQvzQR+uGZNwHBsy ItZLWSB7TUMtVuFujVtZJ9jMOiKegWFwXl6D0= Received: by 10.216.48.1 with SMTP id u1mr2000448web.189.1237236452233; Mon, 16 Mar 2009 13:47:32 -0700 (PDT) Received: from snowcone (92-235-187-79.cable.ubr18.sgyl.blueyonder.co.uk [92.235.187.79]) by mx.google.com with ESMTPS id c14sm320866nfi.76.2009.03.16.13.47.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Mar 2009 13:47:31 -0700 (PDT) Date: Mon, 16 Mar 2009 20:47:17 +0000 From: Ciaran McCreesh To: gentoo-pms@lists.gentoo.org Cc: gentoo-dev@lists.gentoo.org Subject: [gentoo-pms] EAPI 3 PMS Draft Message-ID: <20090316204717.699511f0@snowcone> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Package Manager Specification discussions X-BeenThere: gentoo-pms@gentoo.org X-BeenThere: gentoo-pms@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/qJu90+=yrXgu/km=iuOzurW"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: ff98a869-2ac9-4f47-948d-f9d134a45366 X-Archives-Hash: 32e0e06cf1521dfbf5482848e90507f6 --Sig_/qJu90+=yrXgu/km=iuOzurW Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I've got a very rough draft of what EAPI 3 might end up looking like, based upon discussion: http://github.com/ciaranm/pms/tree/eapi-3 Note that I will probably rebase and modifying the branch quite a bit, so if you don't know how to deal with that when using git, don't track it. It should be one commit per feature, which makes it fairly easy to remove anything that ends up not making it, and very easy to see what's proposed, which currently looks like this: * Introduce eapi 3 * Rework tables for EAPI 3. * EAPI 3 has pkg_pretend. * EAPI 3 supports slot operator dependencies * EAPI 3 has use dependency defaults * PROPERTIES, DEFINED_PHASES mandatory in EAPI 3 * EAPI 3 has a default src_install * EAPI 3 has controllable compression and docompress * EAPI 3 has dodoc -r * EAPI 3 requires doins support for symlinks * EAPI 3 bans || ( use? ( ... ) ) * dohard and dosed banned in EAPI 3 * doinclude, newinclude for EAPI 3 * EAPI 3 supports .xz, .tar.xz * EAPI 3 has more econf arguments * EAPI 3 supports pkg_info on installed packages * USE is stricter in EAPI 3 * Note that (+) won't work on USE_EXPAND etc things * AA, KV gone in EAPI 3 Still to work out: * The exact details for the new USE restrictions. In particular, do we want IUSE_IMPLICIT? We'll also need an accurate list of all possible values for things like LINGUAS. * The [use(+)] thing. For various really pesky reasons, there's no way things like [video_cards_radeon(+)] can be expected to work when applied against EAPIs before 3, but it can be made to work if we know it'll only ever be applied against things with EAPI 3 or later. Is it easier to just say it's never allowed, though? * What's a doexample? * What's default_src_install going to do? I've seen a load of variations. It looks like our choices are between things that ignore docs, making it largely worthless, or things that use a DOCS variable, which Donnie hates (despite making extensive use of such things himself in eclasses). * "Provide ebuilds a way to differentiate between updates and removals". I suggested REPLACING_VERSIONS and REPLACED_BY_VERSION, but I've not had any feedback on that. * "Utility commands, even the ones that aren't functions, should die.". Is Portage likely to be able to do this in the timeframe we're after? * "Calling unpack on an unrecognised extension should be fatal, unless --if-compressed is specified.". There've been questions on this, but no obvious outrage. Is this in or out? * I've left out killing off dohtml. Was a decision reached on that? * RDEPEND=3DDEPEND is still in. Again, was a decision reached? * xz is in, but do we really want to do that when there appears to be nothing stable that can deal with xz? lzma going in was a mistake caused by people being too eager here in exactly the same way they were for making Portage handle xz... * Am I to take it src_test is to remain in its current worthless state? I've probably missed some more things, but I don't know what they are, so if anyone can find any please list them. --=20 Ciaran McCreesh --Sig_/qJu90+=yrXgu/km=iuOzurW Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkm+ut8ACgkQ96zL6DUtXhH2tQCfeH+mY6/saa1mv58TfGJUbFLC Q0sAniKAZjWmETP4/QO2x07dGkbXtLy9 =h04f -----END PGP SIGNATURE----- --Sig_/qJu90+=yrXgu/km=iuOzurW--