* [gentoo-dev] Re: Live source based ebuild proposals Was: [gentoo-council] Council log and summary for meeting on 02/12/09
@ 2009-02-13 20:37 99% ` Ciaran McCreesh
0 siblings, 0 replies; 1+ results
From: Ciaran McCreesh @ 2009-02-13 20:37 UTC (permalink / raw
To: Luca Barbato; +Cc: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 2181 bytes --]
On Fri, 13 Feb 2009 21:29:32 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> > No it doesn't. _pre1, _pre2 etc does not accurately represent how
> > upstream do releases.
>
> 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.
>
> 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.
>
> 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
> 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?
--
Ciaran McCreesh
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
[not found] <20090212214925.GA21532@dodo.hsd1.nj.comcast.net>
[not found] ` <20090213155445.GA31550@dodo.hsd1.nj.comcast.net>
[not found] ` <4995ABE2.4000907@gentoo.org>
[not found] ` <20090213172725.34258824@snowcone>
[not found] ` <4995CB0B.80209@gentoo.org>
[not found] ` <20090213194141.24d44a37@snowcone>
2009-02-13 20:29 ` [gentoo-dev] Live source based ebuild proposals Was: [gentoo-council] Council log and summary for meeting on 02/12/09 Luca Barbato
2009-02-13 20:37 99% ` [gentoo-dev] " Ciaran McCreesh
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox