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 1KBASa-0006dm-FP for garchives@archives.gentoo.org; Tue, 24 Jun 2008 15:29:32 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B7D76E03BE; Tue, 24 Jun 2008 15:29:30 +0000 (UTC) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by pigeon.gentoo.org (Postfix) with ESMTP id 9CCF8E03BE for ; Tue, 24 Jun 2008 15:29:30 +0000 (UTC) Received: by py-out-1112.google.com with SMTP id w53so1631206pyg.25 for ; Tue, 24 Jun 2008 08:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=DbWx9Ql60sf0mlqFViy/o8YSYtn2KecazPp+r7ZGKm8=; b=kBzm1sXQ3SGldNrpWJ7s7CEqyCqoSgIG640K06pjgoLX5If84HnCumCyrMoemwSmny bn2scFudqljLnlqzhvbh5Ak57Wlw3VriMcz8P4bSYcgr2TwD8CR/X5t1DtMiWPwdA/TU +u4E7G0x1l6PWIyRplrfmoTehiWylDUxyu/us= 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=vvF2+vRdKgbecKKnwPJgr3rICVmhjebgkq/khiZ0fvNmad3P9/0vgBfHrQqZJRHDqu Des7Zityz0z4TvmwrL3jvPDF+iBYvkhR5/1m74aEJEA1pJBEbPPdFuoXv8MRiXSK6c8B 7A6WF/BZDihq00RCiEpGSw6xLmaF+94SJ9+zE= Received: by 10.142.194.4 with SMTP id r4mr5731189wff.292.1214321370079; Tue, 24 Jun 2008 08:29:30 -0700 (PDT) Received: from seldon ( [98.210.154.155]) by mx.google.com with ESMTPS id 30sm13084930wff.18.2008.06.24.08.29.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Jun 2008 08:29:29 -0700 (PDT) Date: Tue, 24 Jun 2008 08:29:28 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Merging or overwriting KEYWORDS from eclass Message-ID: <20080624152928.GA7979@seldon.hsd1.ca.comcast.net> References: <200806240153.58516.rbu@gentoo.org> <20080623235520.GA6823@seldon.metaweb.com> 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="huq684BweRXVnRxX" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-Archives-Salt: 5a02cc07-e257-4fcf-ac1d-0e66c3414c1f X-Archives-Hash: d224ed5097cb67622e0fe45cdf2b7d0e --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 24, 2008 at 12:05:39PM +0200, Tiziano M??ller wrote: > Brian Harring wrote: >=20 > > On Tue, Jun 24, 2008 at 01:53:55AM +0200, Robert Buchholz wrote: > >> Hi, > >>=20 > >> I've stumbled upon an inconsitency between package managers the other > >> day [1], which was due to both an ebuild and an eclass defining > >> inconsisting KEYWORDS. > >>=20 > >> bla-1.ebuild: > >> inherit myeclass > >> KEYWORDS=3D"~arch" > >>=20 > >> myeclass.eclass: > >> KEYWORDS=3D"arch" > >>=20 > >> Portage will resolve this by overwriting the variable, so the last > >> (~arch) wins. Paludis, on the other hand, merges the variables, so it > >> is KEYWORDS=3D"~arch arch". > >>=20 > >> The PMS draft [2] defines that "IUSE, DEPEND, RDEPEND and PDEPEND" > >> variables be merged when defined in both eclass and ebuild (Section > >> 7.2), but only says "May be de?ned in an eclass" about KEYWORDS > >> (Section 8.2). > >>=20 > >> Anyone up to toss a coin whose bug it is, and maybe we can have a more > >> specific wording in the PMS? > >=20 > > Paludis bug; if you want KEYWORDS incremental, it'll need to be in > >>=3Deapi2, too nasty of a change to shoehorn into existing (in use) > > eapis. > well, if the PMS doesn't say anything about it, it's a lack of specificat= ion > and not a bug of a package manager. Falls to the same people regardless; in this case it is a bug of the=20 manager since longstanding behaviour of keywords from eclasses has=20 *always* been non-incremental. Regardless, omission of keywords from the list of incremental eclasses=20 doesn't equate to "do what you want"- it means "it's not incremental". > Can you please give more info why this is "too nasty"? The original post gave an example of why this can't be shoehorned in-=20 bla-1, instead of being marked unstable, becomes stable. I might add=20 that it becomes stable effectively *always* also due to stable=20 keywords existing in eclass. The use case for this isn't particularly grand either- the only real=20 use case for such behaviour is shifting unstable keywords into the=20 eclass, and storing the stable keywords in the ebuild. Problem with that however is that if a consumer of the eclass ever=20 needs to be marked unusable (temporarily or otherwise) for a specific=20 arch, the paludis keyword stacking means that the eclass would have to=20 have that arch pruned from the eclass (sticking -$ARCH into the ebuild=20 would most likely not suffice due to existing portage keyword=20 visibility filters). Basically, if we were talking about tweaking IUSE, then I'd be singing=20 a different tune- KEYWORDS behaviour, specifically keywords visibility=20 filtering of available packages means that this isn't easily changable=20 w/out resulting in past managers that worked properly, no longer=20 working properly. For IUSE, you could likely get away with shoehorning this in- older=20 managers generally didn't care much about IUSE (although=20 built_with_use is a notable exception). Cheers. ~brian --huq684BweRXVnRxX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFIYRLXsiLx3HvNzgcRAoOiAJ9bi9QK4ZewYbAusyiaU6G+TPkxUwCgrER9 ngwnnMIfVXbQobU5qLGg+0I= =bo8k -----END PGP SIGNATURE----- --huq684BweRXVnRxX-- -- gentoo-dev@lists.gentoo.org mailing list