Re: [gentoo-dev] [GLEP] scm package version suffix

[Robert Buchholz <rbu@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1491 bytes --]

On Monday, 10. December 2007, Nirbheek Chauhan wrote:
> On Dec 10, 2007 6:29 PM, Robert Buchholz <rbu@gentoo.org> 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


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]