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

2007-12-10 Thread Ciaran McCreesh
On Mon, 10 Dec 2007 13:14:56 +0530
Nirbheek Chauhan [EMAIL PROTECTED] wrote:
 On Dec 10, 2007 12:48 PM, Ciaran McCreesh
 [EMAIL PROTECTED] 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 - 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


signature.asc
Description: PGP signature


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

2007-12-10 Thread Robin H. Johnson
On Mon, Dec 10, 2007 at 07:18:26AM +, Ciaran McCreesh wrote:
 On Sun, 9 Dec 2007 20:31:46 -0800
 Donnie Berkholz [EMAIL PROTECTED] wrote:
  On 18:57 Sun 09 Dec , Ciaran McCreesh wrote:
   On Sun, 09 Dec 2007 19:45:27 +0100
   Jan Kundr??t [EMAIL PROTECTED] 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--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 : [EMAIL PROTECTED]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgpRWwimfpujm.pgp
Description: PGP signature


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

2007-12-10 Thread Ciaran McCreesh
On Mon, 10 Dec 2007 00:26:21 -0800
Robin H. Johnson [EMAIL PROTECTED] 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


signature.asc
Description: PGP signature


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

2007-12-10 Thread Robin H. Johnson
On Mon, Dec 10, 2007 at 08:24:27AM +, 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 : [EMAIL PROTECTED]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgpQtTpDHsLLS.pgp
Description: PGP signature


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

2007-12-10 Thread Ciaran McCreesh
On Mon, 10 Dec 2007 00:36:04 -0800
Robin H. Johnson [EMAIL PROTECTED] wrote:
 On Mon, Dec 10, 2007 at 08:24:27AM +, 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


signature.asc
Description: PGP signature


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

2007-12-10 Thread Robert Buchholz
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


signature.asc
Description: This is a digitally signed message part.


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

2007-12-10 Thread Nirbheek Chauhan
On Dec 10, 2007 6:29 PM, Robert Buchholz [EMAIL PROTECTED] 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
-- 
[EMAIL PROTECTED] mailing list



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

2007-12-10 Thread Robert Buchholz
On Monday, 10. December 2007, Nirbheek Chauhan wrote:
 On Dec 10, 2007 6:29 PM, Robert Buchholz [EMAIL PROTECTED] 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



signature.asc
Description: This is a digitally signed message part.


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

2007-12-10 Thread Nirbheek Chauhan
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



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

2007-12-10 Thread Nirbheek Chauhan
On Dec 11, 2007 1:14 AM, Nirbheek Chauhan [EMAIL PROTECTED] 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
-- 
[EMAIL PROTECTED] mailing list



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

2007-12-09 Thread Josh Sled
Piotr Jaroszyński [EMAIL PROTECTED] 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 [EMAIL PROTECTED]


pgpnfRvZpove4.pgp
Description: PGP signature


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

2007-12-09 Thread Piotr Jaroszyński
Hello,

Attaching the GLEP source.

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

-- 
Best Regards,
Piotr Jaroszyński
GLEP: 54
Title: scm package version suffix
Version: $Revision: $
Last-Modified: $Date: $
Author: Piotr Jaroszyński [EMAIL PROTECTED]
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  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

2007-12-09 Thread Piotr Jaroszyński
On Sunday 09 of December 2007 17:18:08 Josh Sled wrote:
 Piotr Jaroszyński [EMAIL PROTECTED] 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
--
[EMAIL PROTECTED] mailing list



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

2007-12-09 Thread Petteri Räty
Portage versions prior to 2.1.2.12 (included in 2007.0) doesn't handle
arbitrary
version suffixes

doesn't -- don't



signature.asc
Description: OpenPGP digital signature


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

2007-12-09 Thread 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
--
[EMAIL PROTECTED] mailing list



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

2007-12-09 Thread Jan Kundrát
 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



signature.asc
Description: OpenPGP digital signature


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

2007-12-09 Thread Donnie Berkholz
On 18:57 Sun 09 Dec , Ciaran McCreesh wrote:
 On Sun, 09 Dec 2007 19:45:27 +0100
 Jan Kundrát [EMAIL PROTECTED] 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
-- 
[EMAIL PROTECTED] mailing list



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

2007-12-09 Thread Ciaran McCreesh
On Sun, 9 Dec 2007 20:31:46 -0800
Donnie Berkholz [EMAIL PROTECTED] wrote:
 On 18:57 Sun 09 Dec , Ciaran McCreesh wrote:
  On Sun, 09 Dec 2007 19:45:27 +0100
  Jan Kundrát [EMAIL PROTECTED] 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


signature.asc
Description: PGP signature


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

2007-12-09 Thread Nirbheek Chauhan
On Dec 10, 2007 12:48 PM, Ciaran McCreesh
[EMAIL PROTECTED] 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- 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
-- 
[EMAIL PROTECTED] mailing list