| 1 | GLEP: 54 |
1 | GLEP: 54 |
| 2 | Title: scm package version suffix |
2 | Title: scm package version suffix |
| 3 | Version: $Revision: 1.4 $ |
3 | Version: $Revision: 1.5 $ |
| 4 | Last-Modified: $Date: 2007/12/17 18:42:33 $ |
4 | Last-Modified: $Date: 2008/01/06 02:08:59 $ |
| 5 | Author: Piotr Jaroszyński <peper@gentoo.org> |
5 | Author: Piotr Jaroszyński <peper@gentoo.org> |
| 6 | Status: Draft |
6 | Status: Draft |
| 7 | Type: Standards Track |
7 | Type: Standards Track |
| 8 | Content-Type: text/x-rst |
8 | Content-Type: text/x-rst |
| 9 | Created: 09-Dec-2007 |
9 | Created: 09-Dec-2007 |
| … | |
… | |
| 16 | for ebuilds checking out source directly from a source code management system. |
16 | for ebuilds checking out source directly from a source code management system. |
| 17 | |
17 | |
| 18 | Motivation |
18 | Motivation |
| 19 | ========== |
19 | ========== |
| 20 | |
20 | |
| 21 | Currently there is no standard way of marking SCM ebuilds. Using 9999 as the |
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 |
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. |
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 |
24 | Another way is adding a separate package with a -cvs suffix in its name, but |
| 25 | forces to use ``|| ( cat/pkg cat/pkg-cvs )`` dependencies. The closest to what |
25 | that forces the author to use ``|| ( cat/pkg cat/pkg-cvs )`` dependencies. The |
| 26 | is proposed in this GLEP is the ``cvs`` version part, but its implementation is |
26 | closest to what is proposed in this GLEP is the ``cvs`` version part, but its |
| 27 | of very limited use. It has strange comparison rules, no documentation, has |
27 | implementation is of very limited use. It has strange comparison rules, no |
| 28 | never been used in the tree and has a misleading name. |
28 | documentation, has been used sparingly (if ever) and has a misleading name. |
| 29 | |
29 | |
| 30 | The possibility for package managers to recognise SCM ebuilds would allow them |
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 |
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 |
32 | automatic re-installation of SCM packages once a day or week. Any |
| 33 | this GLEP. |
33 | specifications for such features are beyond the scope of this GLEP. |
| 34 | |
34 | |
| 35 | Specification |
35 | Specification |
| 36 | ============= |
36 | ============= |
|
|
37 | |
| 37 | |
38 | |
| 38 | ``scm`` is a special suffix. It can be used on its own, but also in any other |
39 | ``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 | 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 | revision it can be used only once in a version spec, e.g.: |
| 41 | |
42 | |
| … | |
… | |
| 52 | ================== |
53 | ================== |
| 53 | |
54 | |
| 54 | The addition of the scm suffix yields changes in version comparison: |
55 | The addition of the scm suffix yields changes in version comparison: |
| 55 | |
56 | |
| 56 | * When comparing version components from left to right the scm component has the |
57 | * When comparing version components from left to right the scm component has the |
| 57 | highest priority. |
58 | highest priority over other version components. Hence |
|
|
59 | ``pkg-1_alpha-r3 < pkg-1-scm``, 'scm' is greater than 'alpha-r3'. |
| 58 | * Current suffixes with no number part no longer default to zero if they are |
60 | * 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 |
61 | 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 |
62 | to be of a maximum value. Hence ``1_alpha2-scm < 1_alpha-scm``, but still |
| 61 | ``1_alpha == 1_alpha0``. |
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. |
| 62 | |
68 | |
| 63 | Example parsing: |
69 | Example parsing: |
| 64 | |
70 | |
| 65 | * ``cat/pkg-scm > cat/pkg-1`` |
71 | * ``cat/pkg-scm > cat/pkg-1`` |
| 66 | When parsing from left to right the first difference is ``scm`` and |
72 | When parsing from left to right the first difference is ``scm`` and |
Parent Directory
| 
Revision Log
| 
Patch