1 |
� wrote: |
2 |
>> Specification |
3 |
>> ============= |
4 |
>> |
5 |
>> ``scm`` is a special suffix. It can be used on its own, but also in any other |
6 |
>> valid version spec, just before the place where revision would go. And just like |
7 |
>> revision it can be used only once in a version spec, e.g.: |
8 |
>> |
9 |
>> * ``cat/pkg-1.0_alpha0-scm`` |
10 |
>> * ``cat/pkg-1.0_alpha-scm`` |
11 |
>> * ``cat/pkg-1.0-scm-r3`` |
12 |
>> * ``cat/pkg-1-scm`` |
13 |
>> * ``cat/pkg-1-scm-r2`` |
14 |
>> * ``cat/pkg-scm`` |
15 |
>> |
16 |
>> These package atoms are sorted in ascending order (see `Version Comparison`_). |
17 |
> |
18 |
> What is the point of using version information along the scm suffix? |
19 |
> From the logical POV, scm is a special decorator saying "this is a |
20 |
> special tarball that can change in time and we don't know its version |
21 |
> when parsing ebuild, we'd have to ask the repository". Surely I can |
22 |
> think of uses for *revision* specification (as in "revision of the |
23 |
> ebuild"), but why to support full version for scm packages? |
24 |
|
25 |
for example: |
26 |
sys-devel/gcc-4.2.3_p20071127-scm-r1 would be GCC 4.2 branch prerelease |
27 |
with the 20071127 patchset and one ebuild revision. |
28 |
|
29 |
or more generally, why go through the /extra/ trouble of /not/ allowing |
30 |
normal version specifiers? |
31 |
|
32 |
-- |
33 |
looks like christmas at fifty-five degrees |
34 |
this latitude weakens my knees |
35 |
EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 (0xF9A40662) |