| 1 |
> Specification |
| 2 |
> ============= |
| 3 |
> |
| 4 |
> ``scm`` is a special suffix. It can be used on its own, but also in any other |
| 5 |
> valid version spec, just before the place where revision would go. And just like |
| 6 |
> revision it can be used only once in a version spec, e.g.: |
| 7 |
> |
| 8 |
> * ``cat/pkg-1.0_alpha0-scm`` |
| 9 |
> * ``cat/pkg-1.0_alpha-scm`` |
| 10 |
> * ``cat/pkg-1.0-scm-r3`` |
| 11 |
> * ``cat/pkg-1-scm`` |
| 12 |
> * ``cat/pkg-1-scm-r2`` |
| 13 |
> * ``cat/pkg-scm`` |
| 14 |
> |
| 15 |
> These package atoms are sorted in ascending order (see `Version Comparison`_). |
| 16 |
|
| 17 |
What is the point of using version information along the scm suffix? |
| 18 |
From the logical POV, scm is a special decorator saying "this is a |
| 19 |
special tarball that can change in time and we don't know its version |
| 20 |
when parsing ebuild, we'd have to ask the repository". Surely I can |
| 21 |
think of uses for *revision* specification (as in "revision of the |
| 22 |
ebuild"), but why to support full version for scm packages? |
| 23 |
|
| 24 |
Cheers, |
| 25 |
-jkt |
| 26 |
|
| 27 |
-- |
| 28 |
cd /local/pub && more beer > /dev/mouth |
Archives