| 1 |
Ciaran McCreesh wrote: |
| 2 |
> No, but something can represent the most commonly used models. We can't |
| 3 |
> do -scm packages for upstreams that do utterly crazy stuff anyway, so |
| 4 |
> we'll stick to the reasonably sane ones. |
| 5 |
|
| 6 |
So we stick to a subset we assume is what we'd expect from upstream. |
| 7 |
|
| 8 |
> Topic branches can be covered by use flags. |
| 9 |
|
| 10 |
So I cannot track mob, master and devel at the same time with -scm |
| 11 |
alone, I need to get useflag change deeply the ebuild behavior. |
| 12 |
|
| 13 |
That could work fine also if upstream keeps two different version |
| 14 |
management systems (e.g lighttpd). |
| 15 |
|
| 16 |
> 'pu' and 'master' both map onto a single foo-scm package. |
| 17 |
> Version-wise, 'pu' and 'master' are both the same, and their version |
| 18 |
> is greater than any existing release. GLEP 54 models this correctly. |
| 19 |
|
| 20 |
Given you do not want to track both at the same time, if you would like |
| 21 |
to track both of them you either do hack about this (that could work |
| 22 |
even with bare live property on pure versioning since you could say you |
| 23 |
could plainly stick use live in every ebuild and then make the ebuild |
| 24 |
directly fetch master, no matter which pv you get). |
| 25 |
|
| 26 |
>> In short any proposal that includes the "live property" gives you the |
| 27 |
>> same benefits. The live template proposal gives added value to the |
| 28 |
>> thing since it makes possible do more and something more useful since |
| 29 |
>> the reduced scope of interest tracking upstream has in the end. |
| 30 |
> |
| 31 |
> How do I track an upstream who has a 0.34 branch (which is equal to or |
| 32 |
> ahead of the most recent 0.34.x release) a 0.36 branch (which is equal |
| 33 |
> to or ahead of the most recent 0.36.x release) |
| 34 |
|
| 35 |
In those cases is enough take the package version and add one w/out |
| 36 |
requiring any additional version component... |
| 37 |
|
| 38 |
> and a master branch (which is ahead of any release) using the live property? |
| 39 |
|
| 40 |
The current versioning alone cannot do it cleanly. A template approach |
| 41 |
or a "mark for infinity" version component like -scm can for a single |
| 42 |
release apart from a release target. |
| 43 |
|
| 44 |
But then you have to use the "use live-different-branch" to grant the |
| 45 |
same level of "version infinity" to different branches you may want to |
| 46 |
track. |
| 47 |
|
| 48 |
The same trick youd use to track any number of independent branches |
| 49 |
ahead any release could be used with the current versioning system to |
| 50 |
archive the same result: use flags triggering the live property and |
| 51 |
redefining the source accordingly (use live-master, use live-pu, use |
| 52 |
live-mob) in every ebuild for said package. |
| 53 |
|
| 54 |
|
| 55 |
So the bare minimum to keep the tree w/out "hand made infinity" (-9999) |
| 56 |
is just use flags and property live as you just stated here, no strict |
| 57 |
need for -scm for such task. I checked with zmedico and PROPERTIES |
| 58 |
support conditionals so that is the _bare_ minimum to archive the use |
| 59 |
case "I want to track a/any number of non version branch of a/any target |
| 60 |
source controlled tree from upstream" |
| 61 |
|
| 62 |
lu |
| 63 |
|
| 64 |
-- |
| 65 |
|
| 66 |
Luca Barbato |
| 67 |
Gentoo Council Member |
| 68 |
Gentoo/linux Gentoo/PPC |
| 69 |
http://dev.gentoo.org/~lu_zero |
Archives