Recent off-list discussions revealed that understanding of _pXYZ varies among developers. I could not find sufficient definition anywhere on devmanual.gentoo.org, especially neither on [1] or [2]. The precise scenario is this. Upstream has released version 1.2.3 and fixed annoying bug 104 with a patch they made themselves. If that post-released patch "foo-1.2.3-issue-104.patch" is integrated downstream at Gentoo should a) the ebuild revision be increased (e.g. 1.2.3 -> 1.2.3-r1) b) the patch level be increased/appended (e.g. 1.2.3 -> 1.2.3_p1) A definition of the term "patchlevel" and if upstream and/or downstream is the party to make these would be helpful. Thanks in advance! Sebastian [1] http://devmanual.gentoo.org/ebuild-writing/file-format/index.html [2] http://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html
(In reply to comment #0) > Recent off-list discussions revealed that understanding of _pXYZ varies > among developers. I could not find sufficient definition anywhere on > devmanual.gentoo.org, especially neither on [1] or [2]. > > The precise scenario is this. Upstream has released version 1.2.3 and fixed > annoying bug 104 with a patch they made themselves. If that post-released > patch "foo-1.2.3-issue-104.patch" ... I think it all breaks down to the fact that having diff available on github/bitbucket/whatever is not exactly equal *releasing* patch by upstream. If it would be available to download from somewhere as "patchset_X" (so SRC_URI could be used) or upstream released updated tarball named 1.2.3_pX that would be the case to use _pX. In that scenario there also wouldn't any problem with numbering cause you would just follow upstream numeration :) However, if you make some changes (even if they origin in upstream repo) and apply them to package-1.2.3. You're making Gentoo's *specific* change to code that's known by the rest of the world as package-1.2.3. So you make revbump.
-1 Upstream needs to release the patchset out as -p1 or _p1 or whatever for this to apply, otherwise it's a Gentoo specific change and should stay as -r1 Comment #1 seems accurate
I agree with comment #1 and comment #2. _pX denotes an upstream version and is only appropriate if upstream patches are tagged such (app-shells/bash being a prominent example for this). An exception to this are date based versions _preYYYYMMDD or _pYYYYMMDD corresponding to a snapshot of an upstream source repository.
Alright, point taken. If we document that "patchlevel" means "patch releases by upstream (e.g. 4.2-pl24)" not "patches released by upstream" I'm all happy.
Care to submit a patch?
Reassigning to devmanual
This was fixed by: commit ba2e7aa36d41c7a4e2caacd50bb2ae482934b23c Author: Chris Reffett <creffett@gentoo.org> Date: Fri Jan 3 21:50:18 2014 -0500 Clarify difference between _p and -r in ebuild names wrt bug 414867, also mention the normal way of naming snapshots diff --git a/ebuild-writing/file-format/text.xml b/ebuild-writing/file-format/text.xml index 9d00e6b..cffb9e4 100644 --- a/ebuild-writing/file-format/text.xml +++ b/ebuild-writing/file-format/text.xml @@ -70,7 +70,7 @@ what portage considers to be the 'lowest' version comes first. </tr> <tr> <ti>_p</ti> - <ti>Patch level</ti> + <ti>Patch release</ti> </tr> </table> @@ -98,12 +98,19 @@ No integer part of the version may be longer than 18 digits. Finally, version may have a Gentoo revision number in the form <c>-r1</c>. The initial Gentoo version should have no revision suffix, the first revision should be <c>-r1</c>, the second <c>-r2</c> and so on. See <uri link="::general-concepts/ebuild-revisions"/>. +Revision numbers are distinguished from patch releases by revision bumps being +changes by Gentoo developers, while patch releases are new releases by upstream. </p> <p> Overall, this gives us a filename like <c>libfoo-1.2.5b_pre5-r2.ebuild</c>. </p> +<p> +When packaging a snapshot of a source repository, the standard naming format is +$(last-released-version)_pYYYYMMDD +</p> + </body> </section>
Awesome! :)
