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 know when the branch will be merged), etc. > 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. -- ~Nirbheek Chauhan -- [EMAIL PROTECTED] mailing list
