On Dec 11, 2007 5:57 AM, Steve Long <[EMAIL PROTECTED]> wrote:
> I don't find the argument for versioning the scm live ebuild compelling.
> The point wrt comparison, ie foo-1-scm is < 2.0.1, doesn't seem enough; it'd
> be better to slot that imo, and have a slot identifier[1] in the existing
> cvs digit space. You could still have gtk-1-cvs, for example, for packages
> where slots don't work.
Versioning for scm live ebuilds can be useful when you know which
version the branch will be merged in. For example, if you have a
branch "awesome-feature" and you know it will be merged in 2.5, you
could call the ebuild app-misc/blah-2.4-scm_bawesome-feature so that
it will have higher priority over all versions of the package till 2.5
(if we're not doing mutual blocking for versioned branches). In this
case, you'd have automatic upgrading to 2.5 which can be very
desirable if you have lots of such branches to maintain.
>
> I prefer the way it works now; SLOT and cvs compares later than any other
> version in the same slot. (I agree the name is misleading and prefer vcs
> since it collides less than other options.)
>
> foo-vcs-rN # standard vcs (i prefer the explicit 0 of current spec)
> foo-vcsN-rN # slotted pkg
Why not keep slotting the way it is now via the SLOT variable? What
you're suggesting is pkg-scm${SLOT} which can break if you have string
slots, since then pkg-scm${SLOT} could very well be the name of some
other package, say "pkg-scmomg".
> foo-vcs_branch_FOO-rN # branch
Hmmm, I prefer foo-scm_b${BRANCHNAME} it keeps the versioning conciser..
> foo-vcsN_branch_STRING-rN
>
> ..make sense[2] and cover all the use cases that I have read about so far.
> It'd be useful to restrict the STRING to a simple upper case ID with a
> length limit; the ebuild description will give more information to a user
I don't see why there should be a technical length limit to the
STRING. I say it should just use the name of the branch. This way we
can just have one place to get the branch name from (making them
similar to versions this way).
If a branch name is too large (upto the maintainer's discretion), he
can always use something like MY_BRANCH=${REALLY_LONG_BRANCH_NAME}
inside the ebuild and use something else for the ebuild's name.
>
> A numeric slot id with different branches applying to the same slot would
> seem to be enough to track any project over its lifecycle. The id would
> only be visible to users choosing to install a live ebuild when the package
> is slotted.
While it's true that branches will usually not carry over between
slots, I don't see why we have to restrict them to order purely on the
basis of slots.
- If the package has multiple slots, and a branch only applies to one
of them, the ebuild can just use the SLOT variable to restrict it to
that slot.
- If the branch will be merged by version 2.5, version the branch
ebuild as foo-2.4-scm_b${B}
- If ETA for merging is unknown, foo-scm_b${B}
>
> The reason I don't think it's a good idea to allow full versioning is that
> it seems to be clouding the issue. Packages are available, in slots. If the
I don't understand how it's clouding the issue, the versioning system
seems simple enough. Perhaps I'm missing something? Could you please
elaborate?
> user chooses version control, it applies to the slot:pkg combination, and
> beyond that only needs a mechanism to choose which branch to track.
> Maintainers need to track ebuild revisions, and all of us, including
> package managers, can do with keeping things simple, imo.
>
> [1] Since SLOT is one of the most basic items in an ebuild, it's something
> any user making an ebuild is aware of. A vcs ebuild-writer should have no
> problem finding a suitable id, especially if it is to go into the tree.
>
> [2] s/vcs/whatever acronym you prefer/
> -vcsN* and -rN+ (or -r0N+.N+ for prefix portage) in regex terms
> -rN if missing, is implicit -r0 (compares before explicit)
>
--
~Nirbheek Chauhan
--
[EMAIL PROTECTED] mailing list
