Ciaran McCreesh wrote:
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.
So we stick to a subset we assume is what we'd expect from upstream.
Topic branches can be covered by use flags.
So I cannot track mob, master and devel at the same time with -scm
alone, I need to get useflag change deeply the ebuild behavior.
That could work fine also if upstream keeps two different version
management systems (e.g lighttpd).
'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.
Given you do not want to track both at the same time, if you would like
to track both of them you either do hack about this (that could work
even with bare live property on pure versioning since you could say you
could plainly stick use live in every ebuild and then make the ebuild
directly fetch master, no matter which pv you get).
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)
In those cases is enough take the package version and add one w/out
requiring any additional version component...
and a master branch (which is ahead of any release) using the live property?
The current versioning alone cannot do it cleanly. A template approach
or a "mark for infinity" version component like -scm can for a single
release apart from a release target.
But then you have to use the "use live-different-branch" to grant the
same level of "version infinity" to different branches you may want to
track.
The same trick youd use to track any number of independent branches
ahead any release could be used with the current versioning system to
archive the same result: use flags triggering the live property and
redefining the source accordingly (use live-master, use live-pu, use
live-mob) in every ebuild for said package.
So the bare minimum to keep the tree w/out "hand made infinity" (-9999)
is just use flags and property live as you just stated here, no strict
need for -scm for such task. I checked with zmedico and PROPERTIES
support conditionals so that is the _bare_ minimum to archive the use
case "I want to track a/any number of non version branch of a/any target
source controlled tree from upstream"
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
