Gentoo Archives: gentoo-dev

From: Ryan Hill <dirtyepic@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: [GLEP] scm package version suffix
Date: Sun, 09 Dec 2007 19:46:05
Message-Id: fjhg8e$o4j$1@ger.gmane.org
In Reply to: Re: [gentoo-dev] [GLEP] scm package version suffix by "Jan Kundrát"
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)

Attachments

File name MIME type
signature.asc application/pgp-signature