FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 12-09-2007, 03:01 PM
Piotr Jaroszyński
 
Default scm package version suffix

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 <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 :
 
Old 12-09-2007, 03:18 PM
Josh Sled
 
Default scm package version suffix

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}
 
Old 12-09-2007, 04:22 PM
Piotr Jaroszyński
 
Default scm package version suffix

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
 
Old 12-09-2007, 04:52 PM
Petteri Rty
 
Default scm package version suffix

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

doesn't --> don't
 
Old 12-09-2007, 05:00 PM
Piotr Jaroszyński
 
Default scm package version suffix

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
 
Old 12-09-2007, 05:45 PM
Jan Kundrt
 
Default scm package version suffix

> 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
 
Old 12-09-2007, 05:57 PM
Ciaran McCreesh
 
Default scm package version suffix

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

Branches.

--
Ciaran McCreesh
 
Old 12-09-2007, 06:38 PM
Ryan Hill
 
Default scm package version suffix

� 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)
 
Old 12-10-2007, 03:31 AM
Donnie Berkholz
 
Default scm package version suffix

On 18:57 Sun 09 Dec , Ciaran McCreesh wrote:
> On Sun, 09 Dec 2007 19:45:27 +0100
> Jan Kundrt <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
 
Old 12-10-2007, 06:18 AM
Ciaran McCreesh
 
Default scm package version suffix

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 Kundrt <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
 

Thread Tools




All times are GMT. The time now is 06:41 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org