[gentoo-dev] Re: Live source based ebuild proposals Was: [gentoo-council] Council log and summary for meeting on 02/12/09

[Ciaran McCreesh <ciaran.mccreesh@googlemail.com>]

[-- 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 --]