Nirbheek Chauhan wrote: > On Dec 10, 2007 8:44 PM, Robert Buchholz <[EMAIL PROTECTED]> wrote: >> That would still mean everything relies on n ebuilds with mutual blocks. >> Even if that would work and it block upgrades, it is still not a >> solution in terms of how to display a list of ebuilds in one tree in an >> ordered list. > > The mutual blocks can be via the very nature of the name of the ebuild > (ie, the scm_bbranch), and not via unmaintainable dep blocks in the > ebuilds. This could be similar to the way SLOTS are handled. In fact, > as Donnie and Santiago discussed in the other "branch string" thread, > the concept of SLOTS could be extended to branches with no concept of > an "upgrade" between them, and them being mutually blocking and > perhaps blocking the actual package as well. > Of course this could be extended to apply only to branch ebuilds > without a version number (where you don't know when the branch will be > merged), etc. > This makes a lot of sense to me.
If different branches of a vcs build are to come into the tree, it only makes sense they block the main package and each other. Handling that within the package manager makes sense, since it's information that can be derived automatically. At a later stage one can envisage branches being installed to their own prefixes. >> You are right. But this just shows that named feature branches do not >> fit the context of this GLEP, as you usually cannot know when a feature >> will be merged at the time one version is branched. > > Completely removing the concept of an "upgrade" from (unversioned?) > branch ebuilds and making them block all other versions of the package > will give the task of knowing when a feature has been merged to the > user itself. Which is after all what one does manually while working > on branches. > ++ 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. 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 foo-vcs_branch_FOO-rN # branch 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 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. 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 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) -- [EMAIL PROTECTED] mailing list
