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

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

[Piotr Jaroszyński]

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

Hello,

Attaching the GLEP source.

Current html version available here:
http://dev.gentoo.org/~peper/glep-0054.html

-- 
Best Regards,
Piotr Jaroszyński

[-- Attachment #2: glep-0054.txt --]
[-- Type: text/plain, Size: 4063 bytes --]

GLEP: 54
Title: scm package version suffix
Version: $Revision: $
Last-Modified: $Date: $
Author: Piotr Jaroszyński <peper@gentoo.org>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 09-Dec-2007
Post-History: 09-Dec-2007

Abstract
========

This GLEP proposes addition of a new special package version suffix - ``scm`` -
for ebuilds checking out source directly from a source code management system.

Motivation
==========

Currently there is no standard way of marking SCM ebuilds. Using 9999 as the
version is pretty common, but it is handled like any other ebuild and hence
portage cannot provide any additional features for packages with such a version.
Another way is adding separate package with -cvs suffix in its name, but that
forces to use ``|| ( cat/pkg cat/pkg-cvs )`` dependencies. The closest to what
is proposed in this GLEP is the ``cvs`` version part, but its implementation is
of very limited use. It has strange comparison rules, no documentation, has
never been used in the tree and has a misleading name.

The possibility for package managers to recognise SCM ebuilds would allow them
to add features dedicated specially to said ebuilds. One such feature could be
automatic re-installation of SCM packages once a day or week, but that's beyond
this GLEP.

Specification
=============

``scm`` is a special suffix. It can be used on its own, but also in any other
valid version spec, just before the place where revision would go. And just like
revision it can be used only once in a version spec, e.g.:

  *  ``cat/pkg-1.0_alpha0-scm``
  *  ``cat/pkg-1.0_alpha-scm``
  *  ``cat/pkg-1.0-scm-r3``
  *  ``cat/pkg-1-scm``
  *  ``cat/pkg-1-scm-r2``
  *  ``cat/pkg-scm``

These package atoms are sorted in ascending order (see `Version Comparison`_).

Version Comparison
==================

The addition of the scm suffix yields changes in version comparison:

  *  When comparing version components from left to right the scm component has the
     highest priority.
  *  Current suffixes with no number part no longer default to zero if they are
     followed by an scm suffix. If that's the case the number part is considered
     to be of a maximum value. Hence ``1_alpha2-scm < 1_alpha-scm``, but still
     ``1_alpha == 1_alpha0``.

Example parsing:

  *  ``cat/pkg-scm > cat/pkg-1``
       When parsing from left to right the first difference is ``scm`` and
       ``1``. ``cat/pkg-scm`` wins.
  *  ``cat/pkg-1-scm > cat/pkg-1.0-scm``
       When parsing from left to right the first difference is ``scm`` and
       ``0``. ``cat/pkg-1-scm`` wins.
  *  ``cat/pkg-1_alpha-scm > cat/pkg-1_alpha1-scm``
       In the first package version ``alpha`` doesn't have a number part *and*
       is followed by an ``scm`` suffix, hence it is considered to have a maximum
       value as the number part. When parsing from left to right the first
       difference is the number part of the ``alpha`` suffix. Maximum value
       yielded by the following ``scm`` suffix wins with ``1``.

List of version specs in ascending order:

  *  ``1``
  *  ``1.1-scm``
  *  ``1.2_alpha-scm``
  *  ``1.2_beta_p``
  *  ``1.2_beta_p0-scm``
  *  ``1.2_beta_p1-scm``
  *  ``1.2_beta_p-scm``
  *  ``1.2_beta1_p-scm``
  *  ``1.2_beta10``
  *  ``1.2_beta10_p1-scm``
  *  ``1.2_beta10-scm``
  *  ``1.2_beta-scm``
  *  ``1.2``
  *  ``1.2-scm``
  *  ``1.2-scm-r1``
  *  ``1-scm``
  *  ``10``
  *  ``scm``
  *  ``scm-r3``


Backwards Compatibility
=======================

Portage versions prior to 2.1.2.12 (included in 2007.0) doesn't handle arbitrary
version suffixes and die during various tasks making portage hard or impossible
to use. Later versions just ignore them displaying warnings. Hence use of
``scm`` suffixes in gentoo-x86 tree will probably have to wait till 2008.0
release or later.

Copyright
=========

This document has been placed in the public domain.

.. vim: set tw=80 fileencoding=utf-8 spell spelllang=en et :

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

[Josh Sled]

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

Piotr Jaroszyński <peper@gentoo.org> writes:
> Current html version available here:
> http://dev.gentoo.org/~peper/glep-0054.html

Until reading the abstract, I thought this was Scheme related.

I'd suggest "-vc" (version controlled) or "-vcs" instead.

(...not that it matters much, of course.)

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo ${a}@${b}

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

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

[Piotr Jaroszyński]

On Sunday 09 of December 2007 17:18:08 Josh Sled wrote:
> Piotr Jaroszyński <peper@gentoo.org> writes:
> > Current html version available here:
> > http://dev.gentoo.org/~peper/glep-0054.html
>
> Until reading the abstract, I thought this was Scheme related.
>
> I'd suggest "-vc" (version controlled) or "-vcs" instead.

$ wtf vc
vc: nothing appropriate
$ wtf vcs
vcs                  (4)  - virtual console memory
$ wtf scm
SCM: software configuration management
source code management

scm wins :)

-- 
Best Regards,
Piotr Jaroszyński
--
gentoo-dev@gentoo.org mailing list

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

[Petteri Räty]

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

"Portage versions prior to 2.1.2.12 (included in 2007.0) doesn't handle
arbitrary
version suffixes"

doesn't --> don't


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

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

[Piotr Jaroszyński]

On Sunday 09 of December 2007 18:52:22 Petteri Räty wrote:
> "Portage versions prior to 2.1.2.12 (included in 2007.0) doesn't handle
> arbitrary
> version suffixes"
>
> doesn't --> don't

thanks, fixed.

-- 
Best Regards,
Piotr Jaroszyński
--
gentoo-dev@gentoo.org mailing list

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

[Jan Kundrát]

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

> Specification
> =============
> 
> ``scm`` is a special suffix. It can be used on its own, but also in any other
> valid version spec, just before the place where revision would go. And just like
> revision it can be used only once in a version spec, e.g.:
> 
>   *  ``cat/pkg-1.0_alpha0-scm``
>   *  ``cat/pkg-1.0_alpha-scm``
>   *  ``cat/pkg-1.0-scm-r3``
>   *  ``cat/pkg-1-scm``
>   *  ``cat/pkg-1-scm-r2``
>   *  ``cat/pkg-scm``
> 
> These package atoms are sorted in ascending order (see `Version Comparison`_).

What is the point of using version information along the scm suffix?
From the logical POV, scm is a special decorator saying "this is a
special tarball that can change in time and we don't know its version
when parsing ebuild, we'd have to ask the repository". Surely I can
think of uses for *revision* specification (as in "revision of the
ebuild"), but why to support full version for scm packages?

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

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

[Ciaran McCreesh]

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

On Sun, 09 Dec 2007 19:45:27 +0100
Jan Kundrát <jkt@gentoo.org> wrote:
> What is the point of using version information along the scm suffix?

Branches.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Donnie Berkholz]

On 18:57 Sun 09 Dec     , Ciaran McCreesh wrote:
> On Sun, 09 Dec 2007 19:45:27 +0100
> Jan Kundrát <jkt@gentoo.org> wrote:
> > What is the point of using version information along the scm suffix?
> 
> Branches.

How would I handle branches that aren't numbers but are instead strings, 
which seems to grow increasingly more common as VCSs can handle it? Just 
give them arbitrary numbers?

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Sun, 9 Dec 2007 20:31:46 -0800
Donnie Berkholz <dberkholz@gentoo.org> wrote:
> On 18:57 Sun 09 Dec     , Ciaran McCreesh wrote:
> > On Sun, 09 Dec 2007 19:45:27 +0100
> > Jan Kundrát <jkt@gentoo.org> wrote:
> > > What is the point of using version information along the scm
> > > suffix?
> > 
> > Branches.
> 
> How would I handle branches that aren't numbers but are instead
> strings, which seems to grow increasingly more common as VCSs can
> handle it? Just give them arbitrary numbers?

Feature as opposed to release branches would still have to be separate
packages, especially if you need to depend upon a particular feature.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Nirbheek Chauhan]

On Dec 10, 2007 12:48 PM, Ciaran McCreesh
<ciaran.mccreesh@blueyonder.co.uk> wrote:
> Feature as opposed to release branches would still have to be separate
> packages, especially if you need to depend upon a particular feature.

I don't understand how having to depend on a particular feature causes
one to need a separate package. Infact, if a branch has a new feature
that I want to test against a lot of packages, having a separate
package means I have to either || ( sys-apps/package
sys-apps/package-branch ) for all packages that I want to test it
against, or make a virtual package sys-apps/package-9999 which just
depends on sys-apps/package-branch. The former is too much work
sometimes, and the latter just brings us full circle.

Why not just have something like
sys-devel/gcc-4.2.3_p20071127-scm_b${BRANCHNAME}-r1 ?
It should be easy to parse since it'll always be after "scm" and will
be the last portion of the version string before "-rN".
In case ${BRANCHNAME} itself ends in "-rN" (highly unlikely), the
entire version string could be made to end with "-r0" to signify that
it's revision 0 and not revision N.

Also, releases are often tagged rather than being branched out, which
would have to be kept in mind as well.

-- 
~Nirbheek Chauhan
-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Mon, 10 Dec 2007 13:14:56 +0530
"Nirbheek Chauhan" <nirbheek.chauhan@gmail.com> wrote:
> On Dec 10, 2007 12:48 PM, Ciaran McCreesh
> <ciaran.mccreesh@blueyonder.co.uk> wrote:
> > Feature as opposed to release branches would still have to be
> > separate packages, especially if you need to depend upon a
> > particular feature.
> 
> I don't understand how having to depend on a particular feature causes
> one to need a separate package.

Because depending on a particular feature is a whole different kettle
of fish to having a sane alternative to -9999 or -cvs packages. 

> Why not just have something like
> sys-devel/gcc-4.2.3_p20071127-scm_b${BRANCHNAME}-r1 ?

Because it breaks deps. Simplest example: if I
block !=sys-devel/gcc-4.2.3* because of a bug (and gcc isn't an ideal
example here), I'm also blocking branches that don't have said bug.
When this is extended with long-lasting feature branches the situation
gets very very messy.

> Also, releases are often tagged rather than being branched out, which
> would have to be kept in mind as well.

No, for releases you follow the normal version mechanism.

Incidentally, I suspect the gcc example with _p is confusing people. The
normal use for an -scm suffix will be as follows:

    mypkg-1.2.3
    mypkg-1.2.4
    mypkg-scm

Where -scm is a live ebuild that's been package.masked. However, some
packages have several active branches, so you'd get:

    mypkg-1.2.3
    mypkg-1.2.4
    mypkg-1-scm
    mypkg-2.0.1
    mypkg-scm

Where -1-scm is a live ebuild for branches/1/ and -scm is a live ebuild
for trunk/. In particular, observe how 1-scm is < 2.0.1.

The whole _p thing only comes up for those very rare (or possibly
non-existent) projects that have patchset branches that are themselves
live. I highly doubt that many people will make use of anything other
than -scm or -number(.number)-scm. There's no reason to shove an -scm
suffix onto a package made from a static tarball, and the -scm suffix
does not replace existing mechanisms for indicating snapshots.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Robin H. Johnson]

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

On Mon, Dec 10, 2007 at 08:24:27AM +0000, Ciaran McCreesh wrote:
>     mypkg-scm
One devil's advocate question for now.
Regardless of which suffix we pick, given that it is a well-known
suffix, what will be the expected behavior when PN = 'foo-scm'?

There's at least one package on Freshmeat with that name (vrml-scm), and
I have seen another one elsewhere when researching Git conversion tools.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 321 bytes --]

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

[Ciaran McCreesh]

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

On Mon, 10 Dec 2007 00:36:04 -0800
"Robin H. Johnson" <robbat2@gentoo.org> wrote:
> On Mon, Dec 10, 2007 at 08:24:27AM +0000, Ciaran McCreesh wrote:
> >     mypkg-scm
> One devil's advocate question for now.
> Regardless of which suffix we pick, given that it is a well-known
> suffix, what will be the expected behavior when PN = 'foo-scm'?

There isn't a problem. There is never any need to work out whether
something is a cat/pkg or a cat/pkg-ver (things have been carefully
designed that way -- in cases where either is valid, the -ver form
always has an operator too, and all operators require a version). You'd
simply have foo-scm-scm.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Ryan Hill]

Ciaran McCreesh wrote:

> Incidentally, I suspect the gcc example with _p is confusing people. The
> normal use for an -scm suffix will be as follows:

Yeah I abused the _p suffix. My bad.

> The whole _p thing only comes up for those very rare (or possibly
> non-existent) projects that have patchset branches that are themselves
> live.

Actually I was thinking local patchset level.  Using a date was silly
though.  What I'm doing with gcc locally is currently more like:

gcc-4.2.3_pre20071210_p2

(_preDATE is used solely due to restrictions of toolchain.eclass)

Basically I want to force an update
- when the ebuild is edited (_pre)
- when the patchset is updated (_p)

This naming is pretty much the same as the snapshot ebuilds in 
the toolchain overlay, so an -scm suffix to indicate that these
are indeed live SVN ebuilds would be welcome.

I hope this clears up what I meant, to give an example of why one
might want to use version numbers with an -scm suffix.


-- 
                        looks like christmas at fifty-five degrees
                                    this latitude weakens my knees
    EFFD 380E 047A 4B51 D2BD  C64F 8AA8 8346 F9A4 0662 (0xF9A40662)

-- 
gentoo-dev@gentoo.org mailing list

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

[Robert Buchholz]

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

On Monday, 10. December 2007, Nirbheek Chauhan wrote:
> Why not just have something like
> sys-devel/gcc-4.2.3_p20071127-scm_b${BRANCHNAME}-r1 ?

1) You cannot define a total order on those names:
Is
   maa/moo-3-scm_bONECOOLFEATURE
 <
   maa/moo-3-scm_bOTHERCOOLFEATURE
 ?


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.

Regards,
Robert

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

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

[Nirbheek Chauhan]

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.

> 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

-- 
~Nirbheek Chauhan
-- 
gentoo-dev@gentoo.org mailing list

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

[Robert Buchholz]

[-- 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 --]

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

[Nirbheek Chauhan]

On Dec 10, 2007 8:44 PM, Robert Buchholz <rbu@gentoo.org> 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
-- 
gentoo-dev@gentoo.org mailing list

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

[Nirbheek Chauhan]

On Dec 11, 2007 1:14 AM, Nirbheek Chauhan <nirbheek.chauhan@gmail.com> wrote:
> 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.

s/you know/you don't know/

-- 
~Nirbheek Chauhan
-- 
gentoo-dev@gentoo.org mailing list

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

[Steve Long]

Nirbheek Chauhan wrote:

> On Dec 10, 2007 8:44 PM, Robert Buchholz <rbu@gentoo.org> 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)


-- 
gentoo-dev@gentoo.org mailing list

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

[Nirbheek Chauhan]

On Dec 11, 2007 5:57 AM, Steve Long <slong@rathaus.eclipse.co.uk> 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
-- 
gentoo-dev@gentoo.org mailing list

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

[Nirbheek Chauhan]

On Dec 11, 2007 5:57 AM, Steve Long <slong@rathaus.eclipse.co.uk> 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
-- 
gentoo-dev@gentoo.org mailing list

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

[Duncan]

"Nirbheek Chauhan" <nirbheek.chauhan@gmail.com> posted
8b4c83ad0712101144x19e75accm7845221977a6a73f@mail.gmail.com, excerpted
below, on  Tue, 11 Dec 2007 01:14:06 +0530:

> On Dec 10, 2007 8:44 PM, Robert Buchholz <rbu@gentoo.org> 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.

But what about when there's a dependency on any of several branches?  
That gets hard to maintain if there are multiple ebuilds with similar 
dependencies.

However, that's where virtuals come in.  Create a single virtual, depend 
on it, and you have a single dependency instead of a whole complex list 
to maintain in all the various depending ebuilds.  Another alternative of 
course is an eclass, inherited by whatever otherwise depending ebuilds, 
that manages all the dependencies and blockages all in one spot.

Which just means there are existing solutions for that angle, so it's out 
of scope for this GLEP.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

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

[Nirbheek Chauhan]

On Dec 11, 2007 1:51 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> But what about when there's a dependency on any of several branches?
> That gets hard to maintain if there are multiple ebuilds with similar
> dependencies.

How does it become hard to maintain? Different branch ebuilds are
still the same package. For example:

app-misc/foo-1.2 depends on app-misc/bar

branches won't show up in an upgrade, but you can remove app-misc/bar,
do an `emerge --oneshot =app-misc/bar-scm_bfeature` and app-misc/foo's
dependency will be satisfied.
The idea is that no one would want to automatically upgrade to a
branch (because you cannot define "upgrade" for branches), so make it
manual.



-- 
~Nirbheek Chauhan
-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Tue, 11 Dec 2007 16:36:51 +0530
"Nirbheek Chauhan" <nirbheek.chauhan@gmail.com> wrote:
> The idea is that no one would want to automatically upgrade to a
> branch (because you cannot define "upgrade" for branches), so make it
> manual.

...and this is why branches shouldn't be treated like versions. They
have their own set of rules and expected behaviours that are best dealt
with by a different proposal.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Nirbheek Chauhan]

On Dec 11, 2007 4:47 PM, Ciaran McCreesh
<ciaran.mccreesh@blueyonder.co.uk> wrote:
> On Tue, 11 Dec 2007 16:36:51 +0530
> "Nirbheek Chauhan" <nirbheek.chauhan@gmail.com> wrote:
> > The idea is that no one would want to automatically upgrade to a
> > branch (because you cannot define "upgrade" for branches), so make it
> > manual.
>
> ...and this is why branches shouldn't be treated like versions. They
> have their own set of rules and expected behaviours that are best dealt
> with by a different proposal.

I made that statement in the context of unversioned branches where you
do not know when the branch will be merged. In the case where you do
know when the branch will be merged, the versioned branch ebuild can
easily be included in the upgrade list via it's version.
So, you cannot "upgrade" to app-misc/foo-scm_bblah but you *can*
upgrade from app-misc/foo-1.2 to app-misc/foo-1.2-scm_bblahblah and
then finally upgrade to app-misc/foo-1.3 when the branch gets merged.

-- 
~Nirbheek Chauhan
-- 
gentoo-dev@gentoo.org mailing list

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

[Robin H. Johnson]

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

On Mon, Dec 10, 2007 at 07:18:26AM +0000, Ciaran McCreesh wrote:
> On Sun, 9 Dec 2007 20:31:46 -0800
> Donnie Berkholz <dberkholz@gentoo.org> wrote:
> > On 18:57 Sun 09 Dec     , Ciaran McCreesh wrote:
> > > On Sun, 09 Dec 2007 19:45:27 +0100
> > > Jan Kundr??t <jkt@gentoo.org> wrote:
> > > > What is the point of using version information along the scm
> > > > suffix?
> > > 
> > > Branches.
> > 
> > How would I handle branches that aren't numbers but are instead
> > strings, which seems to grow increasingly more common as VCSs can
> > handle it? Just give them arbitrary numbers?
> Feature as opposed to release branches would still have to be separate
> packages, especially if you need to depend upon a particular feature.
What I've got for my Xorg testing setup, is foo-9999-rX, with a number
of different -X values that I just select from via package.{un,}mask
while testing - this saves altering everything else in the tree to pick
some package that has a different name just to satisfy a branch (which
also requires lots of ${MY_PN} mockery for some packages.
You'd also need to put '!cat/pn-feat' in the base cat/pn package and
vice-versa.

Are SCM packages that heavily used that we need to support multiple
branches with dependencies between them?

There's two cases of branches I see (irrelevant of the names used):
Major version branches - eg CVS "cvs-1.11.x" and "cvs-1.12.x" 
(those are the actual upstream branch names, I've seen other packages
using the branch names of 'STABLE', 'OLDSTABLE', 'FEATURE').
Feature-development branches - short-lived branches for the
development of a specific feature - eg the 'atombios-support' branch of
the xorg-video-ati driver (Heavily used in Git repos, where they are
deleted on completion).

Any more styles of branches that other folk have seen?

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 321 bytes --]

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

[Ciaran McCreesh]

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

On Mon, 10 Dec 2007 00:26:21 -0800
"Robin H. Johnson" <robbat2@gentoo.org> wrote:
> There's two cases of branches I see (irrelevant of the names used):
> Major version branches - eg CVS "cvs-1.11.x" and "cvs-1.12.x" 
> (those are the actual upstream branch names, I've seen other packages
> using the branch names of 'STABLE', 'OLDSTABLE', 'FEATURE').

Right. These map to cvs-1.11-scm and cvs-1.12-scm (or you can use
cvs-scm to point to whatever the newest branch is -- whichever is
more convenient).

> Feature-development branches - short-lived branches for the
> development of a specific feature - eg the 'atombios-support' branch
> of the xorg-video-ati driver (Heavily used in Git repos, where they
> are deleted on completion).

And these aren't considered by the proposal. The rationale is as
follows:

If a branch is short lived (your typical git branch), there's no point
having an ebuild for it. If it's long lived, we get into the whole
"which features have been merged into which branch?" mess that can't be
solved by something as simple as version suffixes.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Handling branch strings

[Donnie Berkholz]

On 00:26 Mon 10 Dec     , Robin H. Johnson wrote:
> What I've got for my Xorg testing setup, is foo-9999-rX, with a number
> of different -X values that I just select from via package.{un,}mask
> while testing - this saves altering everything else in the tree to pick
> some package that has a different name just to satisfy a branch (which
> also requires lots of ${MY_PN} mockery for some packages.
> You'd also need to put '!cat/pn-feat' in the base cat/pn package and
> vice-versa.

While we're getting a bit off the original topic here, it occurred to me 
that using SLOTs for this, in combination with various SLOT deps and 
SLOT blockers, might work. Then one could use a search tool that would 
display SLOTs to show you which branch you're getting.

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Handling branch strings

[Santiago M. Mola]

On Dec 10, 2007 10:21 AM, Donnie Berkholz <dberkholz@gentoo.org> wrote:
> On 00:26 Mon 10 Dec     , Robin H. Johnson wrote:
> > What I've got for my Xorg testing setup, is foo-9999-rX, with a number
> > of different -X values that I just select from via package.{un,}mask
> > while testing - this saves altering everything else in the tree to pick
> > some package that has a different name just to satisfy a branch (which
> > also requires lots of ${MY_PN} mockery for some packages.
> > You'd also need to put '!cat/pn-feat' in the base cat/pn package and
> > vice-versa.
>
> While we're getting a bit off the original topic here, it occurred to me
> that using SLOTs for this, in combination with various SLOT deps and
> SLOT blockers, might work. Then one could use a search tool that would
> display SLOTs to show you which branch you're getting.
>

Too tricky. It would confuse package managers and would break the
meaning of SLOT. An use expanded SCM_BRANCH combined with use
dependencies makes more sense and, hopefully, would be something
manageable.

Regards,
Santiago

-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Handling branch strings

[Donnie Berkholz]

On 10:34 Mon 10 Dec     , Santiago M. Mola wrote:
> On Dec 10, 2007 10:21 AM, Donnie Berkholz <dberkholz@gentoo.org> wrote:
> > On 00:26 Mon 10 Dec     , Robin H. Johnson wrote:
> > > What I've got for my Xorg testing setup, is foo-9999-rX, with a number
> > > of different -X values that I just select from via package.{un,}mask
> > > while testing - this saves altering everything else in the tree to pick
> > > some package that has a different name just to satisfy a branch (which
> > > also requires lots of ${MY_PN} mockery for some packages.
> > > You'd also need to put '!cat/pn-feat' in the base cat/pn package and
> > > vice-versa.
> >
> > While we're getting a bit off the original topic here, it occurred to me
> > that using SLOTs for this, in combination with various SLOT deps and
> > SLOT blockers, might work. Then one could use a search tool that would
> > display SLOTs to show you which branch you're getting.
> >
> 
> Too tricky. It would confuse package managers and would break the
> meaning of SLOT. An use expanded SCM_BRANCH combined with use
> dependencies makes more sense and, hopefully, would be something
> manageable.

You've made these assertions about confusion and breakage, and I would 
like to understand the reasoning behind them. I don't understand how it 
would be different than any other SLOT, because they're already a 
string. USE_EXPAND doesn't allow for the possibility of multiple SLOTs 
installed at once, which is a feature I would like.

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Handling branch strings

[Ryan Hill]

Donnie Berkholz wrote:
> On 10:34 Mon 10 Dec     , Santiago M. Mola wrote:
>> On Dec 10, 2007 10:21 AM, Donnie Berkholz <dberkholz@gentoo.org> wrote:

>>> While we're getting a bit off the original topic here, it occurred to me
>>> that using SLOTs for this, in combination with various SLOT deps and
>>> SLOT blockers, might work. Then one could use a search tool that would
>>> display SLOTs to show you which branch you're getting.

>> Too tricky. It would confuse package managers and would break the
>> meaning of SLOT. An use expanded SCM_BRANCH combined with use
>> dependencies makes more sense and, hopefully, would be something
>> manageable.

> You've made these assertions about confusion and breakage, and I would 
> like to understand the reasoning behind them. I don't understand how it 
> would be different than any other SLOT, because they're already a 
> string. USE_EXPAND doesn't allow for the possibility of multiple SLOTs 
> installed at once, which is a feature I would like.

Right, can't you just suffix the SLOT name?  My gcc svn builds just
do SLOT="${GCC_BRANCH_VER}-svn".  This could be a special case though
since a gcc install is pretty carefully separated from its other SLOTs.


-- 
                        looks like christmas at fifty-five degrees
                                    this latitude weakens my knees
    EFFD 380E 047A 4B51 D2BD  C64F 8AA8 8346 F9A4 0662 (0xF9A40662)

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Handling branch strings

[Ciaran McCreesh]

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

On Mon, 10 Dec 2007 11:42:38 -0800
Donnie Berkholz <dberkholz@gentoo.org> wrote:
> You've made these assertions about confusion and breakage, and I
> would like to understand the reasoning behind them. I don't
> understand how it would be different than any other SLOT, because
> they're already a string. USE_EXPAND doesn't allow for the
> possibility of multiple SLOTs installed at once, which is a feature I
> would like.

Conceptually a branch is not a slot (nor is it a version). Reusing an
existing package manager concept for a second, unrelated concept leads
to excessively complicated handling rules and a general nasty mess.

If there's desire for the package manager to be aware of branches, it
should be a separate proposal using a concept specifically designed
for that purpose. Branches exist without SCM, and SCM exists without
branches, and neither have anything to do with slots or use flags.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Handling branch strings

[Santiago M. Mola]

On Dec 11, 2007 9:11 AM, Ciaran McCreesh
<ciaran.mccreesh@blueyonder.co.uk> wrote:
> On Mon, 10 Dec 2007 11:42:38 -0800
> Donnie Berkholz <dberkholz@gentoo.org> wrote:
> > You've made these assertions about confusion and breakage, and I
> > would like to understand the reasoning behind them.
> > [...]

For my reasoning... just read Ciaran's reply ;-)

-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Handling branch strings

[Christian Faulhammer]

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

Donnie Berkholz <dberkholz@gentoo.org>:

> While we're getting a bit off the original topic here, it occurred to
> me that using SLOTs for this, in combination with various SLOT deps
> and SLOT blockers, might work. Then one could use a search tool that
> would display SLOTs to show you which branch you're getting.

$ grep SLOT\= *.ebuild
emacs-18.59-r4.ebuild:SLOT="18"
emacs-21.4-r14.ebuild:SLOT="21"
emacs-22.1-r3.ebuild:SLOT="22"

$ grep SLOT\= *.ebuild
emacs-cvs-22.1.50-r2.ebuild:SLOT="22"
emacs-cvs-23.0.50-r1.ebuild:SLOT="23"
emacs-cvs-23.0.60-r1.ebuild:SLOT="23-unicode"


 That's how we solved it for GNU Emacs...but we had to tackle file
collisions for a while, but now you can have all versions side by
side.  Branches are easily distinguished by version numbers in
upstream's repository, but Emacs may be a special case.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Ryan Hill]

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

� wrote:
>> Specification
>> =============
>>
>> ``scm`` is a special suffix. It can be used on its own, but also in any other
>> valid version spec, just before the place where revision would go. And just like
>> revision it can be used only once in a version spec, e.g.:
>>
>>   *  ``cat/pkg-1.0_alpha0-scm``
>>   *  ``cat/pkg-1.0_alpha-scm``
>>   *  ``cat/pkg-1.0-scm-r3``
>>   *  ``cat/pkg-1-scm``
>>   *  ``cat/pkg-1-scm-r2``
>>   *  ``cat/pkg-scm``
>>
>> These package atoms are sorted in ascending order (see `Version Comparison`_).
> 
> What is the point of using version information along the scm suffix?
> From the logical POV, scm is a special decorator saying "this is a
> special tarball that can change in time and we don't know its version
> when parsing ebuild, we'd have to ask the repository". Surely I can
> think of uses for *revision* specification (as in "revision of the
> ebuild"), but why to support full version for scm packages?

for example:
sys-devel/gcc-4.2.3_p20071127-scm-r1 would be GCC 4.2 branch prerelease
with the 20071127 patchset and one ebuild revision.

or more generally, why go through the /extra/ trouble of /not/ allowing
normal version specifiers?

-- 
                        looks like christmas at fifty-five degrees
                                    this latitude weakens my knees
    EFFD 380E 047A 4B51 D2BD  C64F 8AA8 8346 F9A4 0662 (0xF9A40662)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]