Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 152990 - [PATCH] Portage Local Revisions
Summary: [PATCH] Portage Local Revisions
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Portage team
URL: http://news.gmane.org/find-root.php?m...
Whiteboard:
Keywords:
: 26671 152991 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-10-27 08:28 UTC by Philip Walls (RETIRED)
Modified: 2012-09-06 16:07 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Patch to allow -local# revisions (portage_local_version.patch,3.30 KB, patch)
2006-10-27 08:44 UTC, Philip Walls (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Philip Walls (RETIRED) gentoo-dev 2006-10-27 08:28:08 UTC
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")
Comment 1 Philip Walls (RETIRED) gentoo-dev 2006-10-27 08:40:06 UTC
*** Bug 152991 has been marked as a duplicate of this bug. ***
Comment 2 Philip Walls (RETIRED) gentoo-dev 2006-10-27 08:44:18 UTC
Created attachment 100581 [details, diff]
Patch to allow -local# revisions

Patch is against portage 2.1.2_pre3-r5
Comment 3 Zac Medico gentoo-dev 2006-10-27 21:23:16 UTC
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.
Comment 4 Philip Walls (RETIRED) gentoo-dev 2006-10-30 11:33:34 UTC
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?
Comment 5 Zac Medico gentoo-dev 2006-10-30 12:57:37 UTC
(In reply to comment #4)
> Do I need to write up a GLEP before this patch will be
> accepted?

Yeah, the version format specification is really a core thing, so any changes to it really need a big stamp of approval like that.
Comment 6 Marius Mauch (RETIRED) gentoo-dev 2006-10-30 12:59:16 UTC
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.
Comment 7 Zac Medico gentoo-dev 2006-10-31 12:46:35 UTC
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.
Comment 8 Philip Walls (RETIRED) gentoo-dev 2006-11-01 13:07:07 UTC
Would you like me to post the notice, or is someone from the portage team going to handle it?
Comment 9 Zac Medico gentoo-dev 2006-11-01 13:31:59 UTC
(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.
Comment 10 Philip Walls (RETIRED) gentoo-dev 2006-11-02 06:58:56 UTC
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).
Comment 11 Marius Mauch (RETIRED) gentoo-dev 2006-11-02 15:43:03 UTC
(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.
Comment 12 Philip Walls (RETIRED) gentoo-dev 2006-11-03 07:40:41 UTC
So a patch that would reuse the logic from the base version number scheme in revision numbers would be accepted?
Comment 13 Marius Mauch (RETIRED) gentoo-dev 2007-01-11 12:17:48 UTC
*** Bug 26671 has been marked as a duplicate of this bug. ***
Comment 14 Marius Mauch (RETIRED) gentoo-dev 2007-06-29 06:45:27 UTC
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.
Comment 15 Manuel Rüger (RETIRED) gentoo-dev 2012-09-06 16:00:27 UTC
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.
Comment 16 Zac Medico gentoo-dev 2012-09-06 16:07:32 UTC
(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:

http://www.gentoo.org/proj/en/gentoo-alt/prefix/techdocs.xml#doc_chap2_sect5