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 1NKJNz-0005W7-Da for garchives@archives.gentoo.org; Mon, 14 Dec 2009 22:27:24 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 13057E0C7A for ; Mon, 14 Dec 2009 22:27:23 +0000 (UTC) Received: from mail-yw0-f187.google.com (mail-yw0-f187.google.com [209.85.211.187]) by pigeon.gentoo.org (Postfix) with ESMTP id 93AECE0A8B; Mon, 14 Dec 2009 21:56:12 +0000 (UTC) Received: by ywh17 with SMTP id 17so3872259ywh.2 for ; Mon, 14 Dec 2009 13:56:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=j/NM1G0Yva64axmJ/mb/o1vh5yKBhLv9Om0EwUHnwq0=; b=ALOlYtIOY9UTI3WLBwrpBdZdM2CnLk/+n7BpFRkFVfPvQYJd8zWeFdgDTA3tyACfc6 Q8UU0ZcVeFUfHFDqw3e6sLCdJevgUiPDZd+7atbcQ6DD8LnNpTbGmQSAzFFccr8SKOWM iVBvSmey0f03iocFpOqL5MkCd4Japq1lMsKUA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=gA3T+RDG2LybTSIcREztyr+FftXQwP7fN/YbN+nS0eQOtby60rFBm3Y4yEM8I3uHaR 1Si6FMsnDhDZRqjB7UJCqsqljgvqaBNqjquFlTMRUUJEBeHBB7VWapsfNDEMorj3j7Wj rS+yUPNDf1p9Hfh5WNO8jKpXr+C+JXxPWNmuM= Received: by 10.100.50.36 with SMTP id x36mr2112200anx.151.1260827772160; Mon, 14 Dec 2009 13:56:12 -0800 (PST) Received: from smtp.gmail.com (c-98-210-130-131.hsd1.ca.comcast.net [98.210.130.131]) by mx.google.com with ESMTPS id 15sm2033050yxh.40.2009.12.14.13.56.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Dec 2009 13:56:10 -0800 (PST) Received: by smtp.gmail.com (sSMTP sendmail emulation); Mon, 14 Dec 2009 13:54:28 -0800 Date: Mon, 14 Dec 2009 13:54:28 -0800 From: Brian Harring To: Ulrich Mueller Cc: gentoo-council@lists.gentoo.org, gentoo-pms@lists.gentoo.org Subject: [gentoo-pms] Re: [gentoo-council] eapi3 riders Message-ID: <20091214215428.GH6344@hrair> References: <20091214110923.GE6344@hrair> <19238.8949.965283.91576@a1i15.kph.uni-mainz.de> 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; protocol="application/pgp-signature"; boundary="fWddYNRDgTk9wQGZ" Content-Disposition: inline In-Reply-To: <19238.8949.965283.91576@a1i15.kph.uni-mainz.de> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: 05980b29-3a5c-4fef-a13f-69bb738aaf13 X-Archives-Hash: 1820524fd5657c866aa4f82f3d66f9d2 --fWddYNRDgTk9wQGZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 14, 2009 at 12:35:17PM +0100, Ulrich Mueller wrote: > >>>>> On Mon, 14 Dec 2009, Brian Harring wrote: >=20 > > Just nudging y'all to see if there is any complaints w/ slipping a > > few riders in w/ eapi3 (aka prefix). >=20 > > 1) punting AA > > 2) punting KV and it's friends >=20 > We voted in the last council meeting that we won't put any additional > features into EAPI 3. So I think that you need good arguments if you > want us to revise that decision. It's not addition of a feature... it's removal, thus its exempt- the=20 wording was "no additional features"... right? right? My shitty joke aside, it's zero cost, zero impact for any real world=20 ebuilds (vapier already said he'd punt the involved ebuilds). The reason KV/friends needs to die is that they're basically=20 misleading- majority of kernel aware bits involve /usr/src/linux, only=20 ebuild that seems to need awareness of uname is glibc for nptl and I=20 suspect there are other, better ways (as vapier already said, those=20 ebuilds break down under cross compilation). That said, ignoring KV is viable imo. Punting AA, no cost- it's a=20 worthless var. One less var for new devs to trip on, basically. It's=20 not blatantly hurting anything right now so it could survive. Personally I'd rather not see it's existance continue because we're=20 adhering to the words of the council rather then their intent. =20 Specifically, I presume their intent was to knock this eapi out as=20 quickly as possible- punting AA/KV won't affect that timeline (it's 5=20 minutes worth of implementation time, and 5 of spec time). > 4) Support for unpacking .xz files >=20 > It's an extension, therefore backwards compatible, and zmedico has > already included it in Portage (EAPI=3D3_pre2 has it). >=20 > Should we have a vote per e-mail about the above (1, 2, and 4)? > I think we should finalise the EAPI 3 feature list now and don't > reiterate it at the next council meeting. No argument from me on adding this. It's simple and quick, more=20 importantly it's beneficial to devs. Consider that my +1 as someone who will actually have to implement the=20 support... One additional thought is mtime vdb touching. I'd be tempted to try=20 pushing that one in, specifically requiring implementations that=20 support eapi3 to do this simple touch namely. It's a bit hackish, but=20 is a nice way to nudge PMs to get off their ass and be compliant. Unfortunately that's probably not going to fly since council still=20 hasn't commented. If y'all are open to it, I'd be willing to do the=20 legwork to get it in- if preferred to defer, I understand. ~harring --fWddYNRDgTk9wQGZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEARECAAYFAksmtBQACgkQsiLx3HvNzgdMVACfVimnNCHNnSFmvGssE9TMnUeU CP0AmwWXcFWUarmFaJuj8D7SXaGAkdbz =RFuB -----END PGP SIGNATURE----- --fWddYNRDgTk9wQGZ--