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 1Ld9KK-00086O-SN for garchives@archives.gentoo.org; Fri, 27 Feb 2009 20:28:57 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DB370E01CB; Fri, 27 Feb 2009 20:28:53 +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 83C9CE01CB for ; Fri, 27 Feb 2009 20:28:53 +0000 (UTC) Received: by ewy21 with SMTP id 21so1359546ewy.34 for ; Fri, 27 Feb 2009 12:28:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=FGKKtOi/ThaoP3P5c5iQl0QRGWMIcoH7lIkDkdN7rmc=; b=JbpssvGqIUs1L1JYiHnQ34amCieyoUKLyskotdB0qsW7NEbAATxAcHUSpAz64E3/YY NBmu0cZw02hovRyyGjvDqI4akZ3A/ZMJtMAjhEYvxtg8fF7XTcn5clq57bJCqXwEVBAW rBj4+LPcYsMj/aSIuvzJLPFGr/8lt+1aaDG8s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=XiZKJiUWDC8g80ZJKJMQRkfKYEJ7HR8Baz5kNvaKx7ZRG76u2xdlGyjkSVElsIyzRe FfazA5bhrqPifriJj/67GY8Vot851gf9UwlTsTCukCOOAt2EMaY56VuXdvLpeU2oaPRQ Xo96IBDp28ibi5zoFiwsKWyK2489ik0FgPsoY= Received: by 10.210.141.17 with SMTP id o17mr935271ebd.64.1235766197220; Fri, 27 Feb 2009 12:23:17 -0800 (PST) Received: from snowcone (92-235-187-79.cable.ubr18.sgyl.blueyonder.co.uk [92.235.187.79]) by mx.google.com with ESMTPS id 23sm805861eya.46.2009.02.27.12.23.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Feb 2009 12:23:16 -0800 (PST) Date: Fri, 27 Feb 2009 20:23:05 +0000 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Gentoo Council Reminder for February 26 Message-ID: <20090227202305.0449e50b@snowcone> In-Reply-To: <49A6FE3A.4070205@gentoo.org> References: <20090223072648.GK12339@hermes> <20090225071235.GA3923@comet> <20090226191920.GB3820@comet> <20090226192213.30b2c0c2@snowmobile> <49A6EEAF.4080908@gentoo.org> <20090226193833.62cfa9b8@snowmobile> <49A6FE3A.4070205@gentoo.org> X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; x86_64-pc-linux-gnu) 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; boundary="Sig_/qTIhKnVq6fF/rEmI7YttsvB"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: a279ae65-eb6c-4baf-ba9b-0d565afc36f0 X-Archives-Hash: 5bd96bfa4db538667c45cc4f6d4705e6 --Sig_/qTIhKnVq6fF/rEmI7YttsvB Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 26 Feb 2009 21:40:26 +0100 Luca Barbato wrote: > >> Be specific. Explain how this works when, say, 0.34.4 is current, > >> you have a 0.34.5_live and 0.34.5 comes out. >=20 > being live working as substitute for 0.34.5_preN (_live) component > the appearance of 0.34.5 will be higher than those. If we consider > the .live alternative you'd have 0.34.live that is shadowed only by > 0.35.x So it doesn't work Right. > That is pretty much the same you get with -scm, what happens is that > in the case of live template you have portage installing 0.34.5_preN > with revision informations and adding the template to the "live" set. No, with -scm the order works correctly. > >> How do I track an upstream who has a 0.34 branch (which is equal > >> to or ahead of the most recent 0.34.x release), a 0.36 branch > >> (which is equal to or ahead of the most recent 0.36.x release) and > >> a master branch (which is ahead of any release) using the live > >> property? >=20 > the live property doesn't tell much about versioning > so you could use 9999 as the "x" version component or .live or -scm, > the live property just makes portage aware that the sources are live. >=20 > This situation is one in those pkg-scm and pkg.live work better, but=20 > just for one branch. >=20 > As you said you could address the problem using useflags, so you > could by extension you can use the same way to address the single > case in proposals not supporting the tip of a single non version > branch as well: >=20 > have the all the ebuilds in a package having IUSE=3D-live that if > enabled triggers the live property and changes the src_uri to the > live branch you desire. So if you do that, how does the package manager know that one version is less than another if a particular use flag is enabled, but greater than it if it is disabled? > Again it had been answered in the summary anyway. I thought you had a better answer than "it doesn't work" that I was just missing. Evidently not... --=20 Ciaran McCreesh --Sig_/qTIhKnVq6fF/rEmI7YttsvB Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmoS68ACgkQ96zL6DUtXhEAZwCfUuq5atgn2iIf2ov9gbYFzrm2 yQsAn0qgiqiv/nlw6VUmOR2TmPXV+uep =wUh8 -----END PGP SIGNATURE----- --Sig_/qTIhKnVq6fF/rEmI7YttsvB--