--- xml/htdocs/proj/en/glep/glep-0054.html 2007/10/12 13:01:36 1.4 +++ xml/htdocs/proj/en/glep/glep-0054.html 2007/12/17 18:42:33 1.5 @@ -9,7 +9,7 @@ - GLEP 54 -- An "old-school" metastructure proposal with "boot for being a slacker" Part II + GLEP 54 -- scm package version suffix @@ -30,27 +30,23 @@ GLEP:54 -Title:An "old-school" metastructure proposal with "boot for being a slacker" Part II +Title:scm package version suffix -Version:1.1 +Version:$Revision: 1.5 $ -Last-Modified:2007/10/12 02:08:27 +Last-Modified:$Date: 2007/12/17 18:42:33 $ -Author:Alec Warner <antarus at gentoo.org> +Author:Piotr JaroszyƄski <peper at gentoo.org> -Status:Final +Status:Draft -Type:Informational +Type:Standards Track Content-Type:text/x-rst -Created:11-Oct-2007 +Created:09-Dec-2007 -Replaces:39 - -Requires:39 - -Post-History:11-Oct-2007 +Post-History:09-Dec-2007 @@ -60,65 +56,135 @@

Abstract

-

This GLEP amends GLEP 39[#GLEP39]_. A new project must be announced -to the community prior to it's conception. The announcement should state -the project goals, the plan to achieve those goals, and any other information -deemed useful to the community by the person proposing a new project.

+

This GLEP proposes addition of a new special package version suffix - scm - +for ebuilds checking out source directly from a source code management system.

Motivation

-

Projects were being started behind the scenes that people were not aware of; -this included developers and users alike. It was thought important to notify -the community of new projects. This also enables new projects to get valuable -feedback before getting to far into design and implementation.

-
-
-

Rationale

-

We hope projects receiving feedback fare better in the long run with regards -to general reception as well as meeting the goals set forth in their -announcement. We hope projects announced early get more volunteers by virtue -of being announced and in the community's view.

-
-
-

Backwards Compatibility

-

Projects already announced before 19-Oct-2006 are not affected. Since this -GLEP was authored nearly a year later, conceivably projects announced since -then should retroactively send mail regarding their goals and means to achieve -them if they have not done so already; otherwise they would be in breach of -policy set in 2006.

-
-
-

Specification

-

New projects should send an Request For Comments mail to gentoo-dev (and -optionally gentoo-project) in order to received feedback from the Gentoo -community. Once the feedback has been received and changes incorportated into -the goals and design (if any), the project team should send a mail to -gentoo-dev-announce (and optionally gentoo-announce) regarding it's launch.

-

The contents of the announcements is left intentionally vague as to not -restrict the scope of projects, goals, and means. If announcement, projects, -goals, or means end up being terrible; the authors of this GLEP fully expect -the community to chew you out over it.

-

This GLEP does not empower the community to kill a new project, even if everyone -decides it sucks.

+

Currently there is no standard way of marking SCM ebuilds. Using 9999 as the +version is pretty common, but it is handled like any other ebuild and hence +portage cannot provide any additional features for packages with such a version. +Another way is adding separate package with -cvs suffix in its name, but that +forces to use || ( cat/pkg cat/pkg-cvs ) dependencies. The closest to what +is proposed in this GLEP is the cvs version part, but its implementation is +of very limited use. It has strange comparison rules, no documentation, has +never been used in the tree and has a misleading name.

+

The possibility for package managers to recognise SCM ebuilds would allow them +to add features dedicated specially to said ebuilds. One such feature could be +automatic re-installation of SCM packages once a day or week, but that's beyond +this GLEP.

+
+
+

Specification

+

scm is a special suffix. It can be used on its own, but also in any other +valid version spec, just before the place where revision would go. And just like +revision it can be used only once in a version spec, e.g.:

+
+ +
+

These package atoms are sorted in ascending order (see Version Comparison).

+
+
+

Version Comparison

+

The addition of the scm suffix yields changes in version comparison:

+
+ +
+

Example parsing:

+
+ +
+

List of version specs in ascending order:

+
+ +
+
+
+

Backwards Compatibility

+

Portage versions prior to 2.1.2.12 (included in 2007.0) don't handle arbitrary +version suffixes and die during various tasks making portage hard or impossible +to use. Later versions just ignore them displaying warnings. Hence use of +scm suffixes in gentoo-x86 tree will probably have to wait till 2008.0 +release or later.

Copyright

This document has been placed in the public domain.

+