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 1LY4nW-0001Nm-8y for garchives@archives.gentoo.org; Fri, 13 Feb 2009 20:38:06 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 51ECEE04C5; Fri, 13 Feb 2009 20:38:03 +0000 (UTC) Received: from mail-ew0-f15.google.com (mail-ew0-f15.google.com [209.85.219.15]) by pigeon.gentoo.org (Postfix) with ESMTP id E410EE04C5 for ; Fri, 13 Feb 2009 20:38:02 +0000 (UTC) Received: by ewy8 with SMTP id 8so1194588ewy.10 for ; Fri, 13 Feb 2009 12:38:02 -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:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=5Q0TOWt1iJJ5N4NnraHTGllBPdsSfah1mD8vP8S7Dk0=; b=SeZOUK08U5zwnJS+BkPGSZ8YuJ71aR9jA/v3aQPlRIf+J7fAeJ8VWt//Qy3WW/KWuV aHBvcsHWbmse+k/znV69drwghKQEuXvB8Gu/5ON7/9CAx3xBTUr8utPIAX39DN6LQ94o +MP/wruVqGHIAa9+t+H/rsvxGEvCl7j0pjdBs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=DlAcS4L8kpE0J11c5RxZr3pFcG0XaUWrLtW/O+UtAEGwetRe2HUg8qfgftYxw+2FH8 8Qvs2ILhXlHTIMMHf0qqwFaH7BRtxTZhWQxlSUAgsPELrniP4mY8uh2S3EHSGSgRe3YP wbyv0EklX6A4Zcnv26D0kfglcb97g+7c5EndQ= Received: by 10.210.105.20 with SMTP id d20mr1894825ebc.142.1234557481586; Fri, 13 Feb 2009 12:38:01 -0800 (PST) Received: from snowmobile (92-235-187-79.cable.ubr18.sgyl.blueyonder.co.uk [92.235.187.79]) by mx.google.com with ESMTPS id 7sm3258988eyb.38.2009.02.13.12.38.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Feb 2009 12:38:01 -0800 (PST) Date: Fri, 13 Feb 2009 20:37:58 +0000 From: Ciaran McCreesh To: Luca Barbato Cc: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Re: Live source based ebuild proposals Was: [gentoo-council] Council log and summary for meeting on 02/12/09 Message-ID: <20090213203758.5b04ca93@snowmobile> In-Reply-To: <4995D82C.9080107@gentoo.org> 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> X-Mailer: Claws Mail 3.6.1 (GTK+ 2.14.7; i686-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_/dJ=WMQdgKYRsKhpsXxpda1E"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: 636b3c1d-5ac2-412c-93e3-827e5fb89237 X-Archives-Hash: 387fda785c88d1e51e0ad789d638b0c2 --Sig_/dJ=WMQdgKYRsKhpsXxpda1E Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 13 Feb 2009 21:29:32 +0100 Luca Barbato wrote: > > No it doesn't. _pre1, _pre2 etc does not accurately represent how > > upstream do releases. >=20 > upstream is an undefined entity. We knows already upstreams that > follow a specific version numbering, that tag their release before > time and that even have playground branches where interesting&scary > thing happen, upstreams that keep everything on a single branch and > people doing something insane or worse. >=20 > so NOTHING could represent something unpredictable. No, but something can represent the most commonly used models. We can't do -scm packages for upstreams that do utterly crazy stuff anyway, so we'll stick to the reasonably sane ones. > > And GLEP 54 solves the entire thing. > > It lets you have foo-scm tracking master, foo-2.0-scm tracking the > > 2.0 branch and foo-1.0-scm tracking the 1.0 branch, and the > > ordering all works correctly. It's the only solution anyone's come > > up with that gets this right. >=20 > That doesn't cover the "pu" case brought up by ferdy or another case > in which you plan to track a branch that isn't a version branch or > hasn't a version target, if you want to be strict. So scm solve the > same problem _live solves or plain usage of "property live" within > current ebuilds solves. Topic branches can be covered by use flags. 'pu' and 'master' both map onto a single foo-scm package. Version-wise, 'pu' and 'master' are both the same, and their version is greater than any existing release. GLEP 54 models this correctly. > In short any proposal that includes the "live property" gives you the=20 > same benefits. The live template proposal gives added value to the > thing since it makes possible do more and something more useful since > the reduced scope of interest tracking upstream has in the end. 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 Ciaran McCreesh --Sig_/dJ=WMQdgKYRsKhpsXxpda1E Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkmV2igACgkQ96zL6DUtXhH2dgCfaAjjKeTDQ/B1+hxtf+qH1BpS xdUAoMKJw5hNVdR2MZoGZBr2HB2eaRwK =GHqy -----END PGP SIGNATURE----- --Sig_/dJ=WMQdgKYRsKhpsXxpda1E--