| 1 |
antarus |
1.1 |
GLEP: 54 |
| 2 |
peper |
1.4 |
Title: scm package version suffix |
| 3 |
|
|
Version: $Revision: $ |
| 4 |
|
|
Last-Modified: $Date: $ |
| 5 |
|
|
Author: Piotr Jaroszyński <peper@gentoo.org> |
| 6 |
|
|
Status: Draft |
| 7 |
|
|
Type: Standards Track |
| 8 |
antarus |
1.1 |
Content-Type: text/x-rst |
| 9 |
peper |
1.4 |
Created: 09-Dec-2007 |
| 10 |
|
|
Post-History: 09-Dec-2007 |
| 11 |
antarus |
1.1 |
|
| 12 |
|
|
Abstract |
| 13 |
|
|
======== |
| 14 |
|
|
|
| 15 |
peper |
1.4 |
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 |
antarus |
1.1 |
|
| 18 |
|
|
Motivation |
| 19 |
|
|
========== |
| 20 |
|
|
|
| 21 |
peper |
1.4 |
Currently there is no standard way of marking 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 separate package with -cvs suffix in its name, but that |
| 25 |
|
|
forces to use ``|| ( cat/pkg cat/pkg-cvs )`` dependencies. The closest to what |
| 26 |
|
|
is proposed in this GLEP is the ``cvs`` version part, but its implementation is |
| 27 |
|
|
of very limited use. It has strange comparison rules, no documentation, has |
| 28 |
|
|
never been used in the tree 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, but that's beyond |
| 33 |
|
|
this GLEP. |
| 34 |
antarus |
1.1 |
|
| 35 |
peper |
1.4 |
Specification |
| 36 |
|
|
============= |
| 37 |
antarus |
1.1 |
|
| 38 |
peper |
1.4 |
``scm`` is a special suffix. It can be used on its own, but also in any other |
| 39 |
|
|
valid version spec, just before the place where revision would go. And just like |
| 40 |
|
|
revision it can be used only once in a version spec, e.g.: |
| 41 |
|
|
|
| 42 |
|
|
* ``cat/pkg-1.0_alpha0-scm`` |
| 43 |
|
|
* ``cat/pkg-1.0_alpha-scm`` |
| 44 |
|
|
* ``cat/pkg-1.0-scm-r3`` |
| 45 |
|
|
* ``cat/pkg-1-scm`` |
| 46 |
|
|
* ``cat/pkg-1-scm-r2`` |
| 47 |
|
|
* ``cat/pkg-scm`` |
| 48 |
|
|
|
| 49 |
|
|
These package atoms are sorted in ascending order (see `Version Comparison`_). |
| 50 |
|
|
|
| 51 |
|
|
Version Comparison |
| 52 |
|
|
================== |
| 53 |
|
|
|
| 54 |
|
|
The addition of the scm suffix yields changes in version comparison: |
| 55 |
|
|
|
| 56 |
|
|
* When comparing version components from left to right the scm component has the |
| 57 |
|
|
highest priority. |
| 58 |
|
|
* Current suffixes with no number part no longer default to zero if they are |
| 59 |
|
|
followed by an scm suffix. If that's the case the number part is considered |
| 60 |
|
|
to be of a maximum value. Hence ``1_alpha2-scm < 1_alpha-scm``, but still |
| 61 |
|
|
``1_alpha == 1_alpha0``. |
| 62 |
|
|
|
| 63 |
|
|
Example parsing: |
| 64 |
|
|
|
| 65 |
|
|
* ``cat/pkg-scm > cat/pkg-1`` |
| 66 |
|
|
When parsing from left to right the first difference is ``scm`` and |
| 67 |
|
|
``1``. ``cat/pkg-scm`` wins. |
| 68 |
|
|
* ``cat/pkg-1-scm > cat/pkg-1.0-scm`` |
| 69 |
|
|
When parsing from left to right the first difference is ``scm`` and |
| 70 |
|
|
``0``. ``cat/pkg-1-scm`` wins. |
| 71 |
|
|
* ``cat/pkg-1_alpha-scm > cat/pkg-1_alpha1-scm`` |
| 72 |
|
|
In the first package version ``alpha`` doesn't have a number part *and* |
| 73 |
|
|
is followed by an ``scm`` suffix, hence it is considered to have a maximum |
| 74 |
|
|
value as the number part. When parsing from left to right the first |
| 75 |
|
|
difference is the number part of the ``alpha`` suffix. Maximum value |
| 76 |
|
|
yielded by the following ``scm`` suffix wins with ``1``. |
| 77 |
|
|
|
| 78 |
|
|
List of version specs in ascending order: |
| 79 |
|
|
|
| 80 |
|
|
* ``1`` |
| 81 |
|
|
* ``1.1-scm`` |
| 82 |
|
|
* ``1.2_alpha-scm`` |
| 83 |
|
|
* ``1.2_beta_p`` |
| 84 |
|
|
* ``1.2_beta_p0-scm`` |
| 85 |
|
|
* ``1.2_beta_p1-scm`` |
| 86 |
|
|
* ``1.2_beta_p-scm`` |
| 87 |
|
|
* ``1.2_beta1_p-scm`` |
| 88 |
|
|
* ``1.2_beta10`` |
| 89 |
|
|
* ``1.2_beta10_p1-scm`` |
| 90 |
|
|
* ``1.2_beta10-scm`` |
| 91 |
|
|
* ``1.2_beta-scm`` |
| 92 |
|
|
* ``1.2`` |
| 93 |
|
|
* ``1.2-scm`` |
| 94 |
|
|
* ``1.2-scm-r1`` |
| 95 |
|
|
* ``1-scm`` |
| 96 |
|
|
* ``10`` |
| 97 |
|
|
* ``scm`` |
| 98 |
|
|
* ``scm-r3`` |
| 99 |
antarus |
1.1 |
|
| 100 |
|
|
|
| 101 |
|
|
Backwards Compatibility |
| 102 |
|
|
======================= |
| 103 |
|
|
|
| 104 |
peper |
1.4 |
Portage versions prior to 2.1.2.12 (included in 2007.0) don't handle arbitrary |
| 105 |
|
|
version suffixes and die during various tasks making portage hard or impossible |
| 106 |
|
|
to use. Later versions just ignore them displaying warnings. Hence use of |
| 107 |
|
|
``scm`` suffixes in gentoo-x86 tree will probably have to wait till 2008.0 |
| 108 |
|
|
release or later. |
| 109 |
antarus |
1.1 |
|
| 110 |
|
|
Copyright |
| 111 |
|
|
========= |
| 112 |
|
|
|
| 113 |
|
|
This document has been placed in the public domain. |
| 114 |
|
|
|
| 115 |
peper |
1.4 |
.. vim: set tw=80 fileencoding=utf-8 spell spelllang=en et : |
Parent Directory
| 
Revision Log