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 1LYLi4-0000hw-PO for garchives@archives.gentoo.org; Sat, 14 Feb 2009 14:41:36 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8D1AAE0388; Sat, 14 Feb 2009 14:41:34 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 687F4E0388 for ; Sat, 14 Feb 2009 14:41:34 +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 713B664556 for ; Sat, 14 Feb 2009 14:41:33 +0000 (UTC) Message-ID: <4996D819.8080607@gentoo.org> Date: Sat, 14 Feb 2009 15:41:29 +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] Re: Live source based ebuild proposals References: <20090212214925.GA21532@dodo.hsd1.nj.comcast.net> <20090213155445.GA31550@dodo.hsd1.nj.comcast.net> <4995ABE2.4000907@gentoo.org> <20090213172725.34258824@snowcone> <4995CB0B.80209@gentoo.org> <20090213194141.24d44a37@snowcone> <4995D82C.9080107@gentoo.org> <20090213203758.5b04ca93@snowmobile> <4995F15F.5090505@gentoo.org> <20090213222233.40efa9fd@snowmobile> <4995F5B6.5010003@gentoo.org> <20090213225209.7ef5403e@snowmobile> <4996066E.90306@gentoo.org> <20090213235351.381cffcd@snowmobile> In-Reply-To: <20090213235351.381cffcd@snowmobile> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 2b11fda2-a786-4d0d-978c-f99fd99d3bf0 X-Archives-Hash: 81c676b7338c7c0dd10ce13b0e4684a2 Ciaran McCreesh wrote: > No. Really. Again. You've been steadily talking nonsense on this whole > issue. Please step back, start again and clearly and concisely explain > in coherent English how you solve the simple example I gave earlier in > the thread. I am far from the only person who hasn't managed to work > out your explanation of this simple case so far. Let try to clarify: main problem: - have the possibility to track upstream w/out having to take a manual snapshot of their sources, but having portage automatically fetch them from their tree. current situation: - we have some eclasses that on unpack phase fetch the sources from the upstream server, prepare them and then the usual ebuild process follows. - in order to make an ebuild using those eclasses be valued as the highest possible, the simplest solution had been give it a version "high enough", namely -9999. That makes simple track a single tree per package. - The same could be done with any version component in order to try to track multiple instances, so to track what will be the next 1.5 version, somebody could create an ebuild as 1.4.9999 or 1.5_pre9999, 9999 being an arbitrary big number. -scm proposal: - use a component version that makes whatever before it valued as "the highest within that component", likely -r or _p do, that includes the case "the highest version in absolute" in order to arbitrary decide an "high enough" value, namely -9999. - from what you can find in the glep, the change is apparently purely cosmetic beside the hinted but not expressed possibilities having portage fully aware those ebuild manage something "live" could give. live-properity proposal: - have a property to make portage aware that the ebuild is using live sources. - it doesn't add components to the ebuild version but just marks the ebuild. So this proposal aims to improve portage internal management but doesn't add or detract anything regarding version resolution. live-template proposal: - you still have a new version component, in this case either ".live" or "_live", but in the template. - it isn't used directly in resolution but it generates automatically a normal version that get resolved as usual. - tries to make sure there is a way to get reproducible results regarding installed packages by embedding the informations to get again the same sources. So you can also re-emerge the very same package again you emerged it once since it has a defined version number. - tries to give developers willing to track upstream and then provide snapshots the ability to do that automatically. I hope that is what the various proponents meant with their proposals and that's clear enough. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero