On Monday, 10. December 2007, Nirbheek Chauhan wrote: > On Dec 10, 2007 6:29 PM, Robert Buchholz wrote: > > 1) You cannot define a total order on those names: > > Is > > maa/moo-3-scm_bONECOOLFEATURE > > < > > maa/moo-3-scm_bOTHERCOOLFEATURE > > ? > > Why not have them block each other such that only one branch can be > installed at a time? There can be no concept of "upgrading" between > branches since they all have different features. 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. > > 2) It will break updating from the feature branch, once you > > installed: sys-devel/gcc-4.2.3_p20071127-scm_b${BRANCHNAME}-r1 > > > > and > > sys-devel/gcc-4.2.4 > > > > comes out, it'll update to that, regardless of the inclusion of > > ${BRANCHNAME}'s feature. > > Well, first off, most cases will assume that the branch has been > merged by 4.2.4. Secondly, if the branch has not been merged, and is > continuing independent of the releases, why give it a version number > at all? Just call it sys-devel/gcc-scm_b${BRANCHNAME}-r1 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. Regards, Robert