From: "Piotr Jaroszyński" <peper@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: glep@gentoo.org
Subject: [gentoo-dev] [GLEP] scm package version suffix
Date: Sun, 9 Dec 2007 17:01:49 +0100 [thread overview]
Message-ID: <200712091701.50364.peper@gentoo.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 165 bytes --]
Hello,
Attaching the GLEP source.
Current html version available here:
http://dev.gentoo.org/~peper/glep-0054.html
--
Best Regards,
Piotr Jaroszyński
[-- Attachment #2: glep-0054.txt --]
[-- Type: text/plain, Size: 4063 bytes --]
GLEP: 54
Title: scm package version suffix
Version: $Revision: $
Last-Modified: $Date: $
Author: Piotr Jaroszyński <peper@gentoo.org>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 09-Dec-2007
Post-History: 09-Dec-2007
Abstract
========
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
==========
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.:
* ``cat/pkg-1.0_alpha0-scm``
* ``cat/pkg-1.0_alpha-scm``
* ``cat/pkg-1.0-scm-r3``
* ``cat/pkg-1-scm``
* ``cat/pkg-1-scm-r2``
* ``cat/pkg-scm``
These package atoms are sorted in ascending order (see `Version Comparison`_).
Version Comparison
==================
The addition of the scm suffix yields changes in version comparison:
* When comparing version components from left to right the scm component has the
highest priority.
* Current suffixes with no number part no longer default to zero if they are
followed by an scm suffix. If that's the case the number part is considered
to be of a maximum value. Hence ``1_alpha2-scm < 1_alpha-scm``, but still
``1_alpha == 1_alpha0``.
Example parsing:
* ``cat/pkg-scm > cat/pkg-1``
When parsing from left to right the first difference is ``scm`` and
``1``. ``cat/pkg-scm`` wins.
* ``cat/pkg-1-scm > cat/pkg-1.0-scm``
When parsing from left to right the first difference is ``scm`` and
``0``. ``cat/pkg-1-scm`` wins.
* ``cat/pkg-1_alpha-scm > cat/pkg-1_alpha1-scm``
In the first package version ``alpha`` doesn't have a number part *and*
is followed by an ``scm`` suffix, hence it is considered to have a maximum
value as the number part. When parsing from left to right the first
difference is the number part of the ``alpha`` suffix. Maximum value
yielded by the following ``scm`` suffix wins with ``1``.
List of version specs in ascending order:
* ``1``
* ``1.1-scm``
* ``1.2_alpha-scm``
* ``1.2_beta_p``
* ``1.2_beta_p0-scm``
* ``1.2_beta_p1-scm``
* ``1.2_beta_p-scm``
* ``1.2_beta1_p-scm``
* ``1.2_beta10``
* ``1.2_beta10_p1-scm``
* ``1.2_beta10-scm``
* ``1.2_beta-scm``
* ``1.2``
* ``1.2-scm``
* ``1.2-scm-r1``
* ``1-scm``
* ``10``
* ``scm``
* ``scm-r3``
Backwards Compatibility
=======================
Portage versions prior to 2.1.2.12 (included in 2007.0) doesn'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.
.. vim: set tw=80 fileencoding=utf-8 spell spelllang=en et :
next reply other threads:[~2007-12-09 16:05 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-09 16:01 Piotr Jaroszyński [this message]
2007-12-09 16:18 ` [gentoo-dev] [GLEP] scm package version suffix Josh Sled
2007-12-09 17:22 ` Piotr Jaroszyński
2007-12-09 17:52 ` Petteri Räty
2007-12-09 18:00 ` Piotr Jaroszyński
2007-12-09 18:45 ` Jan Kundrát
2007-12-09 18:57 ` Ciaran McCreesh
2007-12-10 4:31 ` Donnie Berkholz
2007-12-10 7:18 ` Ciaran McCreesh
2007-12-10 7:44 ` Nirbheek Chauhan
2007-12-10 8:24 ` Ciaran McCreesh
2007-12-10 8:36 ` Robin H. Johnson
2007-12-10 8:44 ` Ciaran McCreesh
2007-12-11 1:12 ` [gentoo-dev] " Ryan Hill
2007-12-10 12:59 ` [gentoo-dev] " Robert Buchholz
2007-12-10 14:24 ` Nirbheek Chauhan
2007-12-10 15:14 ` Robert Buchholz
2007-12-10 19:44 ` Nirbheek Chauhan
2007-12-10 19:49 ` Nirbheek Chauhan
2007-12-11 0:27 ` [gentoo-dev] " Steve Long
2007-12-11 10:59 ` Nirbheek Chauhan
2007-12-11 11:03 ` Nirbheek Chauhan
2007-12-11 8:21 ` Duncan
2007-12-11 11:06 ` Nirbheek Chauhan
2007-12-11 11:17 ` Ciaran McCreesh
2007-12-11 12:10 ` Nirbheek Chauhan
2007-12-10 8:26 ` [gentoo-dev] " Robin H. Johnson
2007-12-10 8:34 ` Ciaran McCreesh
2007-12-10 9:21 ` [gentoo-dev] Handling branch strings Donnie Berkholz
2007-12-10 9:34 ` Santiago M. Mola
2007-12-10 19:42 ` Donnie Berkholz
2007-12-11 1:35 ` [gentoo-dev] " Ryan Hill
2007-12-11 8:11 ` [gentoo-dev] " Ciaran McCreesh
2007-12-11 11:46 ` Santiago M. Mola
2007-12-11 17:56 ` [gentoo-dev] " Christian Faulhammer
2007-12-09 19:38 ` [gentoo-dev] Re: [GLEP] scm package version suffix Ryan Hill
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200712091701.50364.peper@gentoo.org \
--to=peper@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
--cc=glep@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox