The URL (Gentoo-dev thread regarding this request) linked gives a detailed description of what I'm asking for here as well as the purpose of such a feature. See the attached patch for a proof of concept of this feature.
This patch allows "-localY" type version numbers, but it has been suggested on the ML that allowing multiple version parts for "-rY" would be preferable (eg. "-rX.Y.Z")
*** Bug 152991 has been marked as a duplicate of this bug. ***
Created attachment 100581 [details, diff]
Patch to allow -local# revisions
Patch is against portage 2.1.2_pre3-r5
I like the -rX.Y.Z idea. It seems like a natural extension of the existing format, since X.Y.Z versions are already supported. I'm a bit wary of changing the version format specification without a GLEP, since it potentially affects our ability to extend the format in other ways that may be necessary in the future.
Zac, do you think we should do simple dotted versions for -r ? I can hack up a patch for this. Do I need to write up a GLEP before this patch will be accepted?
(In reply to comment #4)
> Do I need to write up a GLEP before this patch will be
Yeah, the version format specification is really a core thing, so any changes to it really need a big stamp of approval like that.
If we're going to extend the -r part than I'd strongly oppose to use anything different than the normal versioning rules.
As for a GLEP: Well, I didn't write one when adding the multi-suffix and cvs extensions, and as this isn't supposed to be used in official ebuilds anyway I don't think a GLEP is necessary. However for acceptance I'd like to see a patch for repoman to prevent people from (accidently) committing ebuilds with such local revisions.
I suppose if we give people a final notice about the change on the -dev mailing list so that they have one last chance to discuss it then we should be in the clear.
Would you like me to post the notice, or is someone from the portage team going to handle it?
(In reply to comment #6)
> If we're going to extend the -r part than I'd strongly oppose to use anything
> different than the normal versioning rules.
Do you mean, just numeric x.y.z style, or even more than that? We don't need it to support suffixes like pre|p|beta|alpha|rc do we?
(In reply to comment #8)
> Would you like me to post the notice, or is someone from the portage team going to handle it?
We can handle it, as soon as we have an acceptable patch and we're ready to merge it.
Yes, this is an important clarification to make before I submit the patch. From the gentoo-dev ML most people seemed to agree that it should be integer parts for the version such as "1.5.7" and that versions like "1.02" should not be allowed. The consensus also seemed to be against using "revision suffixes" of any sort (disallow "-r1.5.2b" for example).
(In reply to comment #9)
> (In reply to comment #6)
> > If we're going to extend the -r part than I'd strongly oppose to use anything
> > different than the normal versioning rules.
> Do you mean, just numeric x.y.z style, or even more than that? We don't need
> it to support suffixes like pre|p|beta|alpha|rc do we?
I mean the part between the cvs part and the suffix part in ver_regexp, so
"(\d+)((\.\d+)*)([a-z]?)", using existing comparison rules.
(In reply to comment #10)
> From the gentoo-dev ML most people seemed to agree that it should be integer
> parts for the version such as "1.5.7" and that versions like "1.02" should not
> be allowed. The consensus also seemed to be against using "revision suffixes"
> of any sort (disallow "-r1.5.2b" for example).
Really? The only person I remember being against reusing the current rules was ferringb, and that's just because he doesn't like them (at least I have yet to see an actual reason why this would be bad).
Most other people commenting in that thread just didn't care.
So a patch that would reuse the logic from the base version number scheme in revision numbers would be accepted?
*** Bug 26671 has been marked as a duplicate of this bug. ***
Revisiting this I think I'd go more with the -localY idea than with the -rX.Y approach, as it clarifies the semantic separation (ignoring wether Y is an integer or something more complex) as well as the extension character. But I could live with the -rX.Y as well, it describes the purpose better, it's a tight decision.
Anyway, as soon as Y is something more complex than an integer I still think it should support the full version specification except for the revision part for consistency reasons. Reusing argumentation from the multi-suffix case, what's the point in adding arbitrary technical restrictions that _increase_ code complexity just to prevent _potential_ semantic confusion that likely will never occur? It's not like people have to use all the possibilities they get by the full version specification.
Are there any plans to implement "local revisions"?
The syntax for this problem is still missing:
An overlay includes an ebuild foo-1.1, which is missing from the main tree.
Now foo-1.1 is installed from this overlay, and gets bumped after installation in the main tree.
PM won't rebuild it from the main tree by default.
Now you can change your overlay priorities, so the PM will rebuild foo-1.1.
This solves the problem partially.
- There is no syntax to tell the PM "this overlay has priority XY by default", when adding it via layman. (Maybe something that could be added to profiles/repo_priority ?)
- You can set the priority only for a complete overlay.
(In reply to comment #15)
> Are there any plans to implement "local revisions"?
We could simply merge the inter-revisions support from the prefix branch: