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 1Lcn1v-0008Fg-VH for garchives@archives.gentoo.org; Thu, 26 Feb 2009 20:40:28 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1603CE03C4; Thu, 26 Feb 2009 20:40:26 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id E8B5DE03C4 for ; Thu, 26 Feb 2009 20:40:25 +0000 (UTC) Received: from [192.168.0.9] (unknown [151.57.3.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id F2F4B64E95 for ; Thu, 26 Feb 2009 20:40:24 +0000 (UTC) Message-ID: <49A6FE3A.4070205@gentoo.org> Date: Thu, 26 Feb 2009 21:40:26 +0100 From: Luca Barbato User-Agent: Thunderbird 2.0.0.18 (X11/20081205) 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Gentoo Council Reminder for February 26 References: <20090223072648.GK12339@hermes> <20090225071235.GA3923@comet> <20090226191920.GB3820@comet> <20090226192213.30b2c0c2@snowmobile> <49A6EEAF.4080908@gentoo.org> <20090226193833.62cfa9b8@snowmobile> In-Reply-To: <20090226193833.62cfa9b8@snowmobile> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 08db5de5-9db0-41da-8f16-ee529c344b57 X-Archives-Hash: 0d80ab191e83dbd5543ae786aa2b1a32 Ciaran McCreesh wrote: > On Thu, 26 Feb 2009 20:34:07 +0100 > Luca Barbato wrote: > I'm still waiting for you to answer this: > >> 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. 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 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. This way you can either emerge =0.34.5_preN or emerge @live depending on your needs. And you know that what you have installed since the information is available. I replied in the summary but I guess I had been overly implicit =\ > and this: > >> 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? 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. This situation is one in those pkg-scm and pkg.live work better, but just for one branch. 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: have the all the ebuilds in a package having IUSE=-live that if enabled triggers the live property and changes the src_uri to the live branch you desire. Not exactly the nicest thing but having portage highlighting the case of live ebuilds on -p would maybe partially address it. Again it had been answered in the summary anyway. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero