Re: [gentoo-dev] Re: [GLEP] scm package version suffix

2007-12-11 Thread Nirbheek Chauhan
On Dec 11, 2007 5:57 AM, Steve Long [EMAIL PROTECTED] wrote:
 I don't find the argument for versioning the scm live ebuild compelling.
 The point wrt comparison, ie foo-1-scm is  2.0.1, doesn't seem enough; it'd
 be better to slot that imo, and have a slot identifier[1] in the existing
 cvs digit space. You could still have gtk-1-cvs, for example, for packages
 where slots don't work.

Versioning for scm live ebuilds can be useful when you know which
version the branch will be merged in. For example, if you have a
branch awesome-feature and you know it will be merged in  2.5, you
could call the ebuild app-misc/blah-2.4-scm_bawesome-feature so that
it will have higher priority over all versions of the package till 2.5
(if we're not doing mutual blocking for versioned branches). In this
case, you'd have automatic upgrading to 2.5 which can be very
desirable if you have lots of such branches to maintain.


 I prefer the way it works now; SLOT and cvs compares later than any other
 version in the same slot. (I agree the name is misleading and prefer vcs
 since it collides less than other options.)

 foo-vcs-rN# standard vcs (i prefer the explicit 0 of current spec)
 foo-vcsN-rN   # slotted pkg

Why not keep slotting the way it is now via the SLOT variable? What
you're suggesting is pkg-scm${SLOT} which can break if you have string
slots, since then pkg-scm${SLOT} could very well be the name of some
other package, say pkg-scmomg.

 foo-vcs_branch_FOO-rN # branch

Hmmm, I prefer foo-scm_b${BRANCHNAME} it keeps the versioning conciser..

 foo-vcsN_branch_STRING-rN

 ..make sense[2] and cover all the use cases that I have read about so far.
 It'd be useful to restrict the STRING to a simple upper case ID with a
 length limit; the ebuild description will give more information to a user

I don't see why there should be a technical length limit to the
STRING. I say it should just use the name of the branch. This way we
can just have one place to get the branch name from (making them
similar to versions this way).
If a branch name is too large (upto the maintainer's discretion), he
can always use something like MY_BRANCH=${REALLY_LONG_BRANCH_NAME}
inside the ebuild and use something else for the ebuild's name.


 A numeric slot id with different branches applying to the same slot would
 seem to be enough to track any project over its lifecycle. The id would
 only be visible to users choosing to install a live ebuild when the package
 is slotted.

While it's true that branches will usually not carry over between
slots, I don't see why we have to restrict them to order purely on the
basis of slots.

- If the package has multiple slots, and a branch only applies to one
of them, the ebuild can just use the SLOT variable to restrict it to
that slot.
- If the branch will be merged by version 2.5, version the branch
ebuild as foo-2.4-scm_b${B}
- If ETA for merging is unknown, foo-scm_b${B}


 The reason I don't think it's a good idea to allow full versioning is that
 it seems to be clouding the issue. Packages are available, in slots. If the

I don't understand how it's clouding the issue, the versioning system
seems simple enough. Perhaps I'm missing something? Could you please
elaborate?

 user chooses version control, it applies to the slot:pkg combination, and
 beyond that only needs a mechanism to choose which branch to track.
 Maintainers need to track ebuild revisions, and all of us, including
 package managers, can do with keeping things simple, imo.

 [1] Since SLOT is one of the most basic items in an ebuild, it's something
 any user making an ebuild is aware of. A vcs ebuild-writer should have no
 problem finding a suitable id, especially if it is to go into the tree.

 [2] s/vcs/whatever acronym you prefer/
 -vcsN* and -rN+ (or -r0N+.N+ for prefix portage) in regex terms
 -rN if missing, is implicit -r0 (compares before explicit)




-- 
~Nirbheek Chauhan
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Re: [GLEP] scm package version suffix

2007-12-11 Thread Nirbheek Chauhan
On Dec 11, 2007 1:51 PM, Duncan [EMAIL PROTECTED] wrote:
 But what about when there's a dependency on any of several branches?
 That gets hard to maintain if there are multiple ebuilds with similar
 dependencies.

How does it become hard to maintain? Different branch ebuilds are
still the same package. For example:

app-misc/foo-1.2 depends on app-misc/bar

branches won't show up in an upgrade, but you can remove app-misc/bar,
do an `emerge --oneshot =app-misc/bar-scm_bfeature` and app-misc/foo's
dependency will be satisfied.
The idea is that no one would want to automatically upgrade to a
branch (because you cannot define upgrade for branches), so make it
manual.



-- 
~Nirbheek Chauhan
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Re: [GLEP] scm package version suffix

2007-12-11 Thread Ciaran McCreesh
On Tue, 11 Dec 2007 16:36:51 +0530
Nirbheek Chauhan [EMAIL PROTECTED] wrote:
 The idea is that no one would want to automatically upgrade to a
 branch (because you cannot define upgrade for branches), so make it
 manual.

...and this is why branches shouldn't be treated like versions. They
have their own set of rules and expected behaviours that are best dealt
with by a different proposal.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [GLEP] scm package version suffix

2007-12-11 Thread Nirbheek Chauhan
On Dec 11, 2007 5:57 AM, Steve Long [EMAIL PROTECTED] wrote:
 I don't find the argument for versioning the scm live ebuild compelling.
 The point wrt comparison, ie foo-1-scm is  2.0.1, doesn't seem enough; it'd
 be better to slot that imo, and have a slot identifier[1] in the existing
 cvs digit space. You could still have gtk-1-cvs, for example, for packages
 where slots don't work.

Versioning for scm live ebuilds can be useful when you know which
version the branch will be merged in. For example, if you have a
branch awesome-feature and you know it will be merged in  2.5, you
could call the ebuild app-misc/blah-2.4-scm_bawesome-feature so that
it will have higher priority over all versions of the package till 2.5
(if we're not doing mutual blocking for versioned branches). In this
case, you'd have automatic upgrading to 2.5 which can be very
desirable if you have lots of such branches to maintain.


 I prefer the way it works now; SLOT and cvs compares later than any other
 version in the same slot. (I agree the name is misleading and prefer vcs
 since it collides less than other options.)

 foo-vcs-rN# standard vcs (i prefer the explicit 0 of current spec)
 foo-vcsN-rN   # slotted pkg

Why not keep slotting the way it is now via the SLOT variable? What
you're suggesting is pkg-scm${SLOT} which can break if you have string
slots, since then pkg-scm${SLOT} could very well be the name of some
other package, say pkg-scmomg.

 foo-vcs_branch_FOO-rN # branch

Hmmm, I prefer foo-scm_b${BRANCHNAME} it keeps the versioning conciser..

 foo-vcsN_branch_STRING-rN

 ..make sense[2] and cover all the use cases that I have read about so far.
 It'd be useful to restrict the STRING to a simple upper case ID with a
 length limit; the ebuild description will give more information to a user

I don't see why there should be a technical length limit to the
STRING. I say it should just use the name of the branch. This way we
can just have one place to get the branch name from (making them
similar to versions this way).
If a branch name is too large (upto the maintainer's discretion), he
can always use something like MY_BRANCH=${REALLY_LONG_BRANCH_NAME}
inside the ebuild and use something else for the ebuild's name.


 A numeric slot id with different branches applying to the same slot would
 seem to be enough to track any project over its lifecycle. The id would
 only be visible to users choosing to install a live ebuild when the package
 is slotted.

While it's true that branches will usually not carry over between
slots, I don't see why we have to restrict them to order purely on the
basis of slots.

- If the package has multiple slots, and a branch only applies to one
of them, the ebuild can just use the SLOT variable to restrict it to
that slot.
- If the branch will be merged by version 2.5, version the branch
ebuild as foo-2.4-scm_b${B}
- If ETA for merging is unknown, foo-scm_b${B}


 The reason I don't think it's a good idea to allow full versioning is that
 it seems to be clouding the issue. Packages are available, in slots. If the

I don't understand how it's clouding the issue, the versioning system
seems simple enough. Perhaps I'm missing something? Could you please
elaborate?

 user chooses version control, it applies to the slot:pkg combination, and
 beyond that only needs a mechanism to choose which branch to track.
 Maintainers need to track ebuild revisions, and all of us, including
 package managers, can do with keeping things simple, imo.

 [1] Since SLOT is one of the most basic items in an ebuild, it's something
 any user making an ebuild is aware of. A vcs ebuild-writer should have no
 problem finding a suitable id, especially if it is to go into the tree.

 [2] s/vcs/whatever acronym you prefer/
 -vcsN* and -rN+ (or -r0N+.N+ for prefix portage) in regex terms
 -rN if missing, is implicit -r0 (compares before explicit)




-- 
~Nirbheek Chauhan
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Re: [GLEP] scm package version suffix

2007-12-11 Thread Nirbheek Chauhan
On Dec 11, 2007 4:47 PM, Ciaran McCreesh
[EMAIL PROTECTED] wrote:
 On Tue, 11 Dec 2007 16:36:51 +0530
 Nirbheek Chauhan [EMAIL PROTECTED] wrote:
  The idea is that no one would want to automatically upgrade to a
  branch (because you cannot define upgrade for branches), so make it
  manual.

 ...and this is why branches shouldn't be treated like versions. They
 have their own set of rules and expected behaviours that are best dealt
 with by a different proposal.

I made that statement in the context of unversioned branches where you
do not know when the branch will be merged. In the case where you do
know when the branch will be merged, the versioned branch ebuild can
easily be included in the upgrade list via it's version.
So, you cannot upgrade to app-misc/foo-scm_bblah but you *can*
upgrade from app-misc/foo-1.2 to app-misc/foo-1.2-scm_bblahblah and
then finally upgrade to app-misc/foo-1.3 when the branch gets merged.

-- 
~Nirbheek Chauhan
-- 
[EMAIL PROTECTED] mailing list