On Mon, 10 Dec 2007 13:14:56 +0530
Nirbheek Chauhan [EMAIL PROTECTED] wrote:
On Dec 10, 2007 12:48 PM, Ciaran McCreesh
[EMAIL PROTECTED] wrote:
Feature as opposed to release branches would still have to be
separate packages, especially if you need to depend upon a
particular feature.
I
On Mon, Dec 10, 2007 at 07:18:26AM +, Ciaran McCreesh wrote:
On Sun, 9 Dec 2007 20:31:46 -0800
Donnie Berkholz [EMAIL PROTECTED] wrote:
On 18:57 Sun 09 Dec , Ciaran McCreesh wrote:
On Sun, 09 Dec 2007 19:45:27 +0100
Jan Kundr??t [EMAIL PROTECTED] wrote:
What is the point of
On Mon, 10 Dec 2007 00:26:21 -0800
Robin H. Johnson [EMAIL PROTECTED] wrote:
There's two cases of branches I see (irrelevant of the names used):
Major version branches - eg CVS cvs-1.11.x and cvs-1.12.x
(those are the actual upstream branch names, I've seen other packages
using the branch
On Mon, Dec 10, 2007 at 08:24:27AM +, Ciaran McCreesh wrote:
mypkg-scm
One devil's advocate question for now.
Regardless of which suffix we pick, given that it is a well-known
suffix, what will be the expected behavior when PN = 'foo-scm'?
There's at least one package on Freshmeat with
On Mon, 10 Dec 2007 00:36:04 -0800
Robin H. Johnson [EMAIL PROTECTED] wrote:
On Mon, Dec 10, 2007 at 08:24:27AM +, Ciaran McCreesh wrote:
mypkg-scm
One devil's advocate question for now.
Regardless of which suffix we pick, given that it is a well-known
suffix, what will be the
On Monday, 10. December 2007, Nirbheek Chauhan wrote:
Why not just have something like
sys-devel/gcc-4.2.3_p20071127-scm_b${BRANCHNAME}-r1 ?
1) You cannot define a total order on those names:
Is
maa/moo-3-scm_bONECOOLFEATURE
maa/moo-3-scm_bOTHERCOOLFEATURE
?
2) It will break updating
On Dec 10, 2007 6:29 PM, Robert Buchholz [EMAIL PROTECTED] wrote:
1) You cannot define a total order on those names:
Is
maa/moo-3-scm_bONECOOLFEATURE
maa/moo-3-scm_bOTHERCOOLFEATURE
?
Why not have them block each other such that only one branch can be
installed at a time? There can
On Monday, 10. December 2007, Nirbheek Chauhan wrote:
On Dec 10, 2007 6:29 PM, Robert Buchholz [EMAIL PROTECTED] wrote:
1) You cannot define a total order on those names:
Is
maa/moo-3-scm_bONECOOLFEATURE
maa/moo-3-scm_bOTHERCOOLFEATURE
?
Why not have them block each other
On Dec 10, 2007 8:44 PM, Robert Buchholz [EMAIL PROTECTED] wrote:
That would still mean everything relies on n ebuilds with mutual blocks.
Even if that would work and it block upgrades, it is still not a
solution in terms of how to display a list of ebuilds in one tree in an
ordered list.
The
On Dec 11, 2007 1:14 AM, Nirbheek Chauhan [EMAIL PROTECTED] wrote:
Of course this could be extended to apply only to branch ebuilds
without a version number (where you know when the branch will be
merged), etc.
s/you know/you don't know/
--
~Nirbheek Chauhan
--
[EMAIL PROTECTED] mailing
Piotr Jaroszyński [EMAIL PROTECTED] writes:
Current html version available here:
http://dev.gentoo.org/~peper/glep-0054.html
Until reading the abstract, I thought this was Scheme related.
I'd suggest -vc (version controlled) or -vcs instead.
(...not that it matters much, of course.)
--
Hello,
Attaching the GLEP source.
Current html version available here:
http://dev.gentoo.org/~peper/glep-0054.html
--
Best Regards,
Piotr Jaroszyński
GLEP: 54
Title: scm package version suffix
Version: $Revision: $
Last-Modified: $Date: $
Author: Piotr Jaroszyński [EMAIL PROTECTED]
Status:
On Sunday 09 of December 2007 17:18:08 Josh Sled wrote:
Piotr Jaroszyński [EMAIL PROTECTED] writes:
Current html version available here:
http://dev.gentoo.org/~peper/glep-0054.html
Until reading the abstract, I thought this was Scheme related.
I'd suggest -vc (version controlled) or -vcs
Portage versions prior to 2.1.2.12 (included in 2007.0) doesn't handle
arbitrary
version suffixes
doesn't -- don't
signature.asc
Description: OpenPGP digital signature
On Sunday 09 of December 2007 18:52:22 Petteri Räty wrote:
Portage versions prior to 2.1.2.12 (included in 2007.0) doesn't handle
arbitrary
version suffixes
doesn't -- don't
thanks, fixed.
--
Best Regards,
Piotr Jaroszyński
--
[EMAIL PROTECTED] mailing list
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``
*
On 18:57 Sun 09 Dec , Ciaran McCreesh wrote:
On Sun, 09 Dec 2007 19:45:27 +0100
Jan Kundrát [EMAIL PROTECTED] wrote:
What is the point of using version information along the scm suffix?
Branches.
How would I handle branches that aren't numbers but are instead strings,
which seems to
On Sun, 9 Dec 2007 20:31:46 -0800
Donnie Berkholz [EMAIL PROTECTED] wrote:
On 18:57 Sun 09 Dec , Ciaran McCreesh wrote:
On Sun, 09 Dec 2007 19:45:27 +0100
Jan Kundrát [EMAIL PROTECTED] wrote:
What is the point of using version information along the scm
suffix?
Branches.
How
On Dec 10, 2007 12:48 PM, Ciaran McCreesh
[EMAIL PROTECTED] wrote:
Feature as opposed to release branches would still have to be separate
packages, especially if you need to depend upon a particular feature.
I don't understand how having to depend on a particular feature causes
one to need a
19 matches
Mail list logo
