[gentoo-dev] Re: [GLEP] scm package version suffix
Nirbheek Chauhan [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 11 Dec 2007 01:14:06 +0530: 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 mutual blocks can be via the very nature of the name of the ebuild (ie, the scm_bbranch), and not via unmaintainable dep blocks in the ebuilds. 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. However, that's where virtuals come in. Create a single virtual, depend on it, and you have a single dependency instead of a whole complex list to maintain in all the various depending ebuilds. Another alternative of course is an eclass, inherited by whatever otherwise depending ebuilds, that manages all the dependencies and blockages all in one spot. Which just means there are existing solutions for that angle, so it's out of scope for this GLEP. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [GLEP] scm package version suffix
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
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
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
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
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
[gentoo-dev] Re: [GLEP] scm package version suffix
Nirbheek Chauhan wrote: 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 mutual blocks can be via the very nature of the name of the ebuild (ie, the scm_bbranch), and not via unmaintainable dep blocks in the ebuilds. This could be similar to the way SLOTS are handled. In fact, as Donnie and Santiago discussed in the other branch string thread, the concept of SLOTS could be extended to branches with no concept of an upgrade between them, and them being mutually blocking and perhaps blocking the actual package as well. Of course this could be extended to apply only to branch ebuilds without a version number (where you don't know when the branch will be merged), etc. This makes a lot of sense to me. If different branches of a vcs build are to come into the tree, it only makes sense they block the main package and each other. Handling that within the package manager makes sense, since it's information that can be derived automatically. At a later stage one can envisage branches being installed to their own prefixes. You are right. But this just shows that named feature branches do not fit the context of this GLEP, as you usually cannot know when a feature will be merged at the time one version is branched. Completely removing the concept of an upgrade from (unversioned?) branch ebuilds and making them block all other versions of the package will give the task of knowing when a feature has been merged to the user itself. Which is after all what one does manually while working on branches. ++ 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. 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 foo-vcs_branch_FOO-rN # branch 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 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. 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 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) -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [GLEP] scm package version suffix
Ciaran McCreesh wrote: Incidentally, I suspect the gcc example with _p is confusing people. The normal use for an -scm suffix will be as follows: Yeah I abused the _p suffix. My bad. The whole _p thing only comes up for those very rare (or possibly non-existent) projects that have patchset branches that are themselves live. Actually I was thinking local patchset level. Using a date was silly though. What I'm doing with gcc locally is currently more like: gcc-4.2.3_pre20071210_p2 (_preDATE is used solely due to restrictions of toolchain.eclass) Basically I want to force an update - when the ebuild is edited (_pre) - when the patchset is updated (_p) This naming is pretty much the same as the snapshot ebuilds in the toolchain overlay, so an -scm suffix to indicate that these are indeed live SVN ebuilds would be welcome. I hope this clears up what I meant, to give an example of why one might want to use version numbers with an -scm suffix. -- looks like christmas at fifty-five degrees this latitude weakens my knees EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 (0xF9A40662) -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [GLEP] scm package version suffix
� wrote: 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`_). What is the point of using version information along the scm suffix? From the logical POV, scm is a special decorator saying this is a special tarball that can change in time and we don't know its version when parsing ebuild, we'd have to ask the repository. Surely I can think of uses for *revision* specification (as in revision of the ebuild), but why to support full version for scm packages? for example: sys-devel/gcc-4.2.3_p20071127-scm-r1 would be GCC 4.2 branch prerelease with the 20071127 patchset and one ebuild revision. or more generally, why go through the /extra/ trouble of /not/ allowing normal version specifiers? -- looks like christmas at fifty-five degrees this latitude weakens my knees EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 (0xF9A40662) signature.asc Description: OpenPGP digital signature
