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 1LcJCR-0003Ey-El for garchives@archives.gentoo.org; Wed, 25 Feb 2009 12:49:19 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 56663E0519; Wed, 25 Feb 2009 12:49:17 +0000 (UTC) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by pigeon.gentoo.org (Postfix) with ESMTP id 128D7E0519 for ; Wed, 25 Feb 2009 12:49:17 +0000 (UTC) Received: by rv-out-0506.google.com with SMTP id g9so2817238rvb.2 for ; Wed, 25 Feb 2009 04:49:16 -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:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=aJHfARMdpfzXHOY4YysET0caz7yf6WNsXNMHr2gn+5M=; b=aL++Wgnac5mb+XbfeykxBFTqcpoTa6weZts/Ao3JpOw5/At//AIB/G7WxJGGyg/njd 7iPqZUz/67zEhPrsrlk54imDvu4ACZhablUM0QSShvLM/7TKrD6Yz3lpzUzhU5o1uGrD KszWBSKVCwKuv6IQ8/ZSFGGzyi4mTh49oi2Ek= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Kt39/YdZDvsI794rFlWP9HJnoDu2MCLFQUwGWzGzrdJXp5wa/3KnWfL/9LpMmHy1Df y/xxxVnlKYa7ifr1H4gtEucZJ6BA3LBYBcTQ5CnipZRtgAwm/bUeHF5jMrj61nUYbVSV 0GjEvO/gka3dLXslTMojIr6318wcimEytjAeo= Received: by 10.142.155.17 with SMTP id c17mr35359wfe.223.1235566156630; Wed, 25 Feb 2009 04:49:16 -0800 (PST) Received: from smtp.gmail.com (c-98-210-196-21.hsd1.ca.comcast.net [98.210.196.21]) by mx.google.com with ESMTPS id 28sm10338752wfg.11.2009.02.25.04.49.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Feb 2009 04:49:15 -0800 (PST) Received: by smtp.gmail.com (sSMTP sendmail emulation); Wed, 25 Feb 2009 04:49:51 -0800 Date: Wed, 25 Feb 2009 04:49:51 -0800 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives Message-ID: <20090225124951.GD3506@hrair> References: <49A472E3.1010204@gentoo.org> 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; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cHMo6Wbp1wrKhbfi" Content-Disposition: inline In-Reply-To: <49A472E3.1010204@gentoo.org> User-Agent: Mutt/1.5.16 (2007-06-09) X-Archives-Salt: e62fd2cf-fae2-4234-92b3-ae7eac062766 X-Archives-Hash: 697351856e95c15a4f901a43b4504555 --cHMo6Wbp1wrKhbfi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 25, 2009 at 12:21:23AM +0200, Petteri R??ty wrote: > My notes so far: >=20 > 1) Status quo > - does not allow changing inherit > - bash version in global scope > - global scope in general is quite locked down >=20 > 2) EAPI in file extension > - Allows changing global scope and the internal format of the ebuild > a) .ebuild- > - ignored by current Portage > b) ..ebuild > - current Portage does not work with this > c) .. > - ignored by current Portage >=20 > 3) EAPI in locked down place in the ebuild > - Allows changing global scope > - EAPI can't be changed in an existing ebuild so the PM can trust > the value in the cache > - Does not allow changing versioning rules unless version becomes a > normal metadata variable > * Needs more accesses to cache as now you don't have to load older > versions if the latest is not masked > a) > b) new subdirectory like ebuilds/ > - we could drop extension all together so don't have to argue about > it any more > - more directory reads to get the list of ebuilds in a repository > c) .ebuild in current directory > - needs one year wait 4) eapi as a function; instead of "EAPI=3D1", do "eapi 1", required as=20 the first statement (simplest way). pros: - global scope changes can occur (inherit mechanism changes=20 included). - expanding on the first, auto inherits (pkg level) are possible-=20 effectively when eapi gets invoked the manager is in control and=20 can do whatever is desired setting up the env wise. - bash version requirements can be leveled (bash parses as it goes,=20 meaning that essentially it won't parse what follows 'eapi 2' till=20 that command statement finishes) - fits w/ the existing semantics nicely enough. cons: - mangling the version rules for pkgs still isn't possible; no -scm. =20 Arguable if -scm is even desired, but being explicit about it not=20 covering this. - transition is slightly icky; basically one of the following is=20 required- a) for EAPI>=3D2, do 'eapi 3 || die "upgrade your manager"'. Reason=20 for this is that current managers obviously lack an eapi function,=20 to make managers available *now* blow up the || die is required. =20 This solution can be deployed now, no transition required although=20 at some point stating "eapi is required retroactively for all=20 eapis" would be wise to eliminate the need for the || die (cut=20 support basically for old managers) b) bashrc trickery, defines an eapi if it's unset. Said eapi=20 function exports EAPI=3D$1, optionally triggering a die if the eapi=20 isn't 0,1,2 (since any later eapi would require a manager upgrade=20 which would also have the eapi function). Personally, if g54 is ixnayed #4 I tend to think is the best option=20 out there- if g54 is forced in, g55 (or at least something that=20 adjusts the extension to make it invisible to current managers) is=20 required. Commentary? Tend to think #4 is the most aesthetically pleasing to=20 folk, but who knows... ~harring --cHMo6Wbp1wrKhbfi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmlPm8ACgkQsiLx3HvNzgfb8ACeKzrPOfYj730MA4ukxGxR49a6 xqYAnAkn0sbf6g92Ngp0bcTmtDFZTT7y =vpYZ -----END PGP SIGNATURE----- --cHMo6Wbp1wrKhbfi--