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 1Mp9LS-0001ud-IM for garchives@archives.gentoo.org; Sat, 19 Sep 2009 23:27:58 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 347A2E099E; Sat, 19 Sep 2009 23:27:58 +0000 (UTC) Received: from mail-ew0-f222.google.com (mail-ew0-f222.google.com [209.85.219.222]) by pigeon.gentoo.org (Postfix) with ESMTP id D68AFE099E for ; Sat, 19 Sep 2009 23:27:57 +0000 (UTC) Received: by ewy22 with SMTP id 22so1922843ewy.14 for ; Sat, 19 Sep 2009 16:27:57 -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:in-reply-to:references:x-mailer:mime-version :content-type; bh=21jt3sm/287olxFVbIfEunL+phlOHMBZDZ66jO9t2cY=; b=tBstYc4/1Nd4ELthb/7Iju2vYpU8pQz6znP7H5qZ9lInVXjZu7GIQb2ir9Znnj47l0 S/73Ilmmvj/4bEDj4cML1CiDdM8RBTKPoY/Wxpvh2cg3WMYkLmve46tG5ORS9iEjdTTr +oitWlWNOt+6pyHcqMul+ir9/UxCOLznMH6FA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=bWklX4P5/Ll7q4fUCDnaNa1FEtUGtME6eurx1N/W0Ca7R5RU++JPNjglf2SsPema6z JjPlaTWrTGj85To4WiqAd1feHkuAKTuh2xCi1foa1qFSMcD4V/Lx+mZNi4fl1Fcfj+dQ QFvGyMlZgJcTsoVPxYSHF/v+3D1osCLckX3r4= Received: by 10.210.154.20 with SMTP id b20mr1259885ebe.29.1253402877148; Sat, 19 Sep 2009 16:27:57 -0700 (PDT) Received: from snowmobile (92-235-187-79.cable.ubr18.sgyl.blueyonder.co.uk [92.235.187.79]) by mx.google.com with ESMTPS id 7sm4946535eyb.36.2009.09.19.16.27.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 19 Sep 2009 16:27:57 -0700 (PDT) Date: Sun, 20 Sep 2009 00:27:51 +0100 From: Ciaran McCreesh To: Andrew D Kirch Cc: Ulrich Mueller , Patrick Lauer , gentoo-pms@lists.gentoo.org Subject: Re: [gentoo-pms] tree-layout.tex small cleanup Message-ID: <20090920002751.03b5e9b3@snowmobile> In-Reply-To: <4AB5670D.3030901@trelane.net> References: <200909192215.41235.patrick@gentoo.org> <20090919212541.269df025@snowcone> <200909192234.39415.patrick@gentoo.org> <20090919214515.6b314a3f@snowmobile> <19125.21814.705689.833261@a1i15.kph.uni-mainz.de> <20090919231135.0539253b@snowmobile> <4AB55BBA.9070908@trelane.net> <20090919233849.1d7713f3@snowmobile> <4AB5670D.3030901@trelane.net> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.5; i686-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; micalg=PGP-SHA1; boundary="Sig_/iB1p9HGkf/EHHux39qkaXKe"; protocol="application/pgp-signature" X-Archives-Salt: b86675d4-9364-40c1-a2ff-fdea1a860bb5 X-Archives-Hash: 4d3eb9f2cb2621287f04b44d84201742 --Sig_/iB1p9HGkf/EHHux39qkaXKe Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 19 Sep 2009 19:19:41 -0400 Andrew D Kirch wrote: > > Please explain what you mean. EAPIs are conceptually independent, > > and don't deprecate each other in any kind of way, and future EAPI > > releases can't retroactively change what previous EAPIs said. > > =20 > There's no reason why a subsequent EAPI cannot modify or remove > behavior created in a previous EAPI. If you mean "EAPIs don't have to include every feature that was included in a previous EAPI, and can do things differently from previous EAPIs" then sure. See, for example, dohard and dosed being removed in EAPI 3. If you mean that "EAPIs can change the meaning of older EAPIs", then you're wildly misunderstanding how the whole thing works. We couldn't use EAPI 3 to say that "it's illegal for EAPI 0, 1 and 2 things to use dohard and dosed"; that would defeat half of the point of having EAPIs. > >> This is a specifications document, not a history lesson covering > >> past mistakes. > > > > Getting off-topic here, but which parts of kdebuild-1 do you think > > were mistakes? Given how kdebuild-1 features are making their way > > into EAPIs 2, 3 and beyond as Portage gains support for them, I'm > > sure you don't mean that every feature was wrong, so which of the > > remaining ones do you think shouldn't be adopted and why? > > =20 > kdebuild itself wasn't a mistake, that it made it in when it's not > used was. Explain please. kdebuild-1 was used. --=20 Ciaran McCreesh --Sig_/iB1p9HGkf/EHHux39qkaXKe Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAkq1aPoACgkQ96zL6DUtXhHelQCdEm3dOfx2LjmivXDNgKKGTUec b7MAoNIHxV4ocepKjDvqiswLbxqYQ1ZN =zAlT -----END PGP SIGNATURE----- --Sig_/iB1p9HGkf/EHHux39qkaXKe--