| 1 |
GLEP: 54
|
| 2 |
Title: scm package version suffix
|
| 3 |
Version: $Revision: 1.4 $
|
| 4 |
Last-Modified: $Date: 2007/12/17 18:42:33 $
|
| 5 |
Author: Piotr Jaroszyński <peper@gentoo.org>
|
| 6 |
Status: Draft
|
| 7 |
Type: Standards Track
|
| 8 |
Content-Type: text/x-rst
|
| 9 |
Created: 09-Dec-2007
|
| 10 |
Post-History: 09-Dec-2007
|
| 11 |
|
| 12 |
Abstract
|
| 13 |
========
|
| 14 |
|
| 15 |
This GLEP proposes addition of a new special package version suffix - ``scm`` -
|
| 16 |
for ebuilds checking out source directly from a source code management system.
|
| 17 |
|
| 18 |
Motivation
|
| 19 |
==========
|
| 20 |
|
| 21 |
Currently there is no standard way of identifying SCM ebuilds. Using 9999 as the
|
| 22 |
version is pretty common, but it is handled like any other ebuild and hence
|
| 23 |
portage cannot provide any additional features for packages with such a version.
|
| 24 |
Another way is adding a separate package with a -cvs suffix in its name, but
|
| 25 |
that forces the author to use ``|| ( cat/pkg cat/pkg-cvs )`` dependencies. The
|
| 26 |
closest to what is proposed in this GLEP is the ``cvs`` version part, but its
|
| 27 |
implementation is of very limited use. It has strange comparison rules, no
|
| 28 |
documentation, has been used sparingly (if ever) and has a misleading name.
|
| 29 |
|
| 30 |
The possibility for package managers to recognise SCM ebuilds would allow them
|
| 31 |
to add features dedicated specially to said ebuilds. One such feature could be
|
| 32 |
automatic re-installation of SCM packages once a day or week. Any
|
| 33 |
specifications for such features are beyond the scope of this GLEP.
|
| 34 |
|
| 35 |
Specification
|
| 36 |
=============
|
| 37 |
|
| 38 |
|
| 39 |
``scm`` is a special suffix. It can be used on its own, but also in any other
|
| 40 |
valid version spec, just before the place where revision would go. And just like
|
| 41 |
revision it can be used only once in a version spec, e.g.:
|
| 42 |
|
| 43 |
* ``cat/pkg-1.0_alpha0-scm``
|
| 44 |
* ``cat/pkg-1.0_alpha-scm``
|
| 45 |
* ``cat/pkg-1.0-scm-r3``
|
| 46 |
* ``cat/pkg-1-scm``
|
| 47 |
* ``cat/pkg-1-scm-r2``
|
| 48 |
* ``cat/pkg-scm``
|
| 49 |
|
| 50 |
These package atoms are sorted in ascending order (see `Version Comparison`_).
|
| 51 |
|
| 52 |
Version Comparison
|
| 53 |
==================
|
| 54 |
|
| 55 |
The addition of the scm suffix yields changes in version comparison:
|
| 56 |
|
| 57 |
* When comparing version components from left to right the scm component has the
|
| 58 |
highest priority over other version components. Hence
|
| 59 |
``pkg-1_alpha-r3 < pkg-1-scm``, 'scm' is greater than 'alpha-r3'.
|
| 60 |
* Current suffixes with no number part no longer default to zero if they are
|
| 61 |
followed by an scm suffix. If that's the case the number part is considered
|
| 62 |
to be of a maximum value. Hence ``1_alpha2-scm < 1_alpha-scm``, but still
|
| 63 |
``1_alpha == 1_alpha0``. The rationale behind this choice is to allow
|
| 64 |
multiple branches. For instance imagine a package with an alpha branch
|
| 65 |
and multiple scm releases, as the following: ``alpha-scm``,
|
| 66 |
``alpha2-scm``, ``alpha3-scm`` and so forth. The desired outcome is
|
| 67 |
for ``alpha-scm`` to be greater than all other branches of the same tree.
|
| 68 |
|
| 69 |
Example parsing:
|
| 70 |
|
| 71 |
* ``cat/pkg-scm > cat/pkg-1``
|
| 72 |
When parsing from left to right the first difference is ``scm`` and
|
| 73 |
``1``. ``cat/pkg-scm`` wins.
|
| 74 |
* ``cat/pkg-1-scm > cat/pkg-1.0-scm``
|
| 75 |
When parsing from left to right the first difference is ``scm`` and
|
| 76 |
``0``. ``cat/pkg-1-scm`` wins.
|
| 77 |
* ``cat/pkg-1_alpha-scm > cat/pkg-1_alpha1-scm``
|
| 78 |
In the first package version ``alpha`` doesn't have a number part *and*
|
| 79 |
is followed by an ``scm`` suffix, hence it is considered to have a maximum
|
| 80 |
value as the number part. When parsing from left to right the first
|
| 81 |
difference is the number part of the ``alpha`` suffix. Maximum value
|
| 82 |
yielded by the following ``scm`` suffix wins with ``1``.
|
| 83 |
|
| 84 |
List of version specs in ascending order:
|
| 85 |
|
| 86 |
* ``1``
|
| 87 |
* ``1.1-scm``
|
| 88 |
* ``1.2_alpha-scm``
|
| 89 |
* ``1.2_beta_p``
|
| 90 |
* ``1.2_beta_p0-scm``
|
| 91 |
* ``1.2_beta_p1-scm``
|
| 92 |
* ``1.2_beta_p-scm``
|
| 93 |
* ``1.2_beta1_p-scm``
|
| 94 |
* ``1.2_beta10``
|
| 95 |
* ``1.2_beta10_p1-scm``
|
| 96 |
* ``1.2_beta10-scm``
|
| 97 |
* ``1.2_beta-scm``
|
| 98 |
* ``1.2``
|
| 99 |
* ``1.2-scm``
|
| 100 |
* ``1.2-scm-r1``
|
| 101 |
* ``1-scm``
|
| 102 |
* ``10``
|
| 103 |
* ``scm``
|
| 104 |
* ``scm-r3``
|
| 105 |
|
| 106 |
|
| 107 |
Backwards Compatibility
|
| 108 |
=======================
|
| 109 |
|
| 110 |
Portage versions prior to 2.1.2.12 (included in 2007.0) don't handle arbitrary
|
| 111 |
version suffixes and die during various tasks making portage hard or impossible
|
| 112 |
to use. Later versions just ignore them displaying warnings. Hence use of
|
| 113 |
``scm`` suffixes in gentoo-x86 tree will probably have to wait till 2008.0
|
| 114 |
release or later.
|
| 115 |
|
| 116 |
Copyright
|
| 117 |
=========
|
| 118 |
|
| 119 |
This document has been placed in the public domain.
|
| 120 |
|
| 121 |
.. vim: set tw=80 fileencoding=utf-8 spell spelllang=en et :
|
Parent Directory
| 
Revision Log