1 |
On Fri, 13 Feb 2009 23:17:03 +0100 |
2 |
Luca Barbato <lu_zero@g.o> wrote: |
3 |
> Ciaran McCreesh wrote: |
4 |
> > No, but something can represent the most commonly used models. We |
5 |
> > can't do -scm packages for upstreams that do utterly crazy stuff |
6 |
> > anyway, so we'll stick to the reasonably sane ones. |
7 |
> |
8 |
> So we stick to a subset we assume is what we'd expect from upstream. |
9 |
|
10 |
Yupyup. That was what we had in mind when we worked out -scm. |
11 |
|
12 |
> > Topic branches can be covered by use flags. |
13 |
> |
14 |
> So I cannot track mob, master and devel at the same time with -scm |
15 |
> alone, I need to get useflag change deeply the ebuild behavior. |
16 |
|
17 |
If you're looking to track topics rather than versions, yes. Using |
18 |
versions to track topics gets extremely messy. |
19 |
|
20 |
> > How do I track an upstream who has a 0.34 branch (which is equal to |
21 |
> > or ahead of the most recent 0.34.x release) a 0.36 branch (which |
22 |
> > is equal to or ahead of the most recent 0.36.x release) |
23 |
> |
24 |
> In those cases is enough take the package version and add one w/out |
25 |
> requiring any additional version component... |
26 |
|
27 |
Be specific. Explain how this works when, say, 0.34.4 is current, you |
28 |
have a 0.34.5_live and 0.34.5 comes out. |
29 |
|
30 |
> > and a master branch (which is ahead of any release) using the live |
31 |
> > property? |
32 |
> |
33 |
> The current versioning alone cannot do it cleanly. |
34 |
|
35 |
Hence -scm... |
36 |
|
37 |
-- |
38 |
Ciaran McCreesh |