I thought that naming package-4.0rc2 is wrong as guided by DevManual. However, it turned out it follows PEP-440. On a similar note, otherpackage-1.62b is a beta and per PEP-440 it should be really considered as a beta, and eventually superseded by final 1.62 release. Gentoo believes it should have been released after 1.62 and 1.62a went out. In both cases, DevManual asks/suggests the opposite. It would be nice if it at least explained that there are other, valied rules to file namings. http://www.python.org/dev/peps/pep-0440/#pre-releases It should show how to write an ebuild when package package-4.0rc2 unpacks into package-4.0rc2 while the ebuild file had to be named package-4.0_rc2. Then emerge of course fails to find ${S} and there are some trickeries to fix the S variable easily and quickly. Not only, also the SRC_URI links suffer from the different naming convention and therefore "${PV}" does not work similarly due to 'offending' underscore. I believe this quite common and the DevManual should give examples right away.
The devmanual seems to be pretty clear on this already: Quoting http://devmanual.gentoo.org/ebuild-writing/file-format/index.html > The version section is more complicated. It consists of one or more > numbers separated by full stop (or period, or dot, or decimal point) > characters (eg 1.2.3, 20050108). The final number may have a single > letter following it (e.g. 1.2b). This letter should not be used to > indicate 'beta' status — portage treats 1.2b as being a later version > than 1.2 or 1.2a. > > There can be a suffix to version indicating the kind of release. In > the following table, what portage considers to be the 'lowest' version > comes first. > Suffix Meaning > _alpha Alpha release (earliest) > _beta Beta release > _pre Pre release > _rc Release candidate > (no suffix) Normal release > _p Patch level > > Any of these suffixes may be followed by a non-zero positive integer. So it already says that '#.#rc#' is invalid for ${PV}, and that '#.#b' should not be used to indicate beta status, the way PEP-440 does. It's worth noting that your original thought is correct -- naming a gentoo package 'package-4.0rc2' is wrong as guided by DevManual. For GENTOO packages (ie ebuilds), there are not other valid forms of package naming. What upstream does is up to upstream and it really doesn't matter if they follow a standard or not; gentoo package versions have to stay consistent. As for adjusting S, PV, SRC_URI, etc; well, that's what ebuild writers do. :) There is already plenty of documentation related to using 'versionator' to handle complicated PV manipulation, or you can always use bash parameter expansion to do it. See http://devmanual.gentoo.org/ebuild-writing/variables/index.html#version-and-name-formatting-issues So all of that said, we always are looking to improve things. Could you attach a particular wording suggestion or patch against the devmanual, that would make this clearer per your intentions?
(In reply to Ian Stakenvicius from comment #1) > So it already says that '#.#rc#' is invalid for ${PV}, and that '#.#b' > should not be used to indicate beta status, the way PEP-440 does. Where did you read that in the document? I don't see it and per http://www.freelists.org/post/mira_talk/mira-announce-Release-Candidate-2-for-MIRA-40,1 thread it seems the PEP-404 says opposite. I will try to get back to you after I find the sed-like rules and re-read the manual. ;)
(In reply to Martin Mokrejš from comment #2) > (In reply to Ian Stakenvicius from comment #1) > > > So it already says that '#.#rc#' is invalid for ${PV}, and that '#.#b' > > should not be used to indicate beta status, the way PEP-440 does. > > Where did you read that in the document? The devmanual explicitly states that a "letter should not be used to indicate 'beta' status". And it should be obvious that only those suffixes which are listed in the table are allowed for ebuilds :) Different upstreams (Perl, Python, GNOME, KDE, ...) all have different versioning conventions. Different distro package formats (Gentoo ebuilds, Debian .deb files, Fedora .rpm etc.) also all have different versioning conventions. For simple cases ("foobar-1.0") these all match, but there are some exceptions, like with PEP-440's notion of beta versions. The upstream developer clearly must follow the UPSTREAM convention when picking a version and tarball filename for his source code, and the ebuild writer must follow the GENTOO convention when choosing the ebuild version. For example, the upstream package "mira-4.0rc2" becomes "mira-4.0_rc2" when packaged for Gentoo, and "mira_4.0~rc2-1" when packaged for Debian or Ubuntu.
(In reply to Alexandre Rostovtsev from comment #3) > (In reply to Martin Mokrejš from comment #2) > > (In reply to Ian Stakenvicius from comment #1) > > > > > So it already says that '#.#rc#' is invalid for ${PV}, and that '#.#b' > > > should not be used to indicate beta status, the way PEP-440 does. > > > > Where did you read that in the document? > > The devmanual explicitly states that a "letter should not be used to > indicate 'beta' status". > > And it should be obvious that only those suffixes which are listed in the > table are allowed for ebuilds :) > > Different upstreams (Perl, Python, GNOME, KDE, ...) all have different > versioning conventions. Different distro package formats (Gentoo ebuilds, > Debian .deb files, Fedora .rpm etc.) also all have different versioning > conventions. For simple cases ("foobar-1.0") these all match, but there are > some exceptions, like with PEP-440's notion of beta versions. The upstream > developer clearly must follow the UPSTREAM convention when picking a version > and tarball filename for his source code, and the ebuild writer must follow > the GENTOO convention when choosing the ebuild version. > > For example, the upstream package "mira-4.0rc2" becomes "mira-4.0_rc2" when > packaged for Gentoo, and "mira_4.0~rc2-1" when packaged for Debian or Ubuntu. I agree with all of this, no doubt. I just misunderstood Ian as it seemed to me he interpreted PEP-404 in a different way. Forget that. To move ahead with this, the lousy section in http://devmanual.gentoo.org/ebuild-writing/variables/index.html#version-and-name-formatting-issues does not bother to say what the tiny code really does. Using big formulations just barely mentioning "bash substituion" and "sed, awk and / or cut to do this" are useless. Each of the alternatives should be linked to an example so that I could see what you talk about. Each should be decorated by comments so that I can see the differences and judge what is the difference. So, what does this do? MY_PV=$(replace_version_separator 2 '-') Much more helpful is: # find /usr/portage/ -name \*.ebuild | while read f; do grep MY_PV $f; done I propose these constructs be explained in that paragraph.: MY_PV="${PV%_alpha*}a-${PV#*_alpha}" MY_PV="${PV/_/}" MY_PV=${PV/_/-} MY_PV=$(get_version_component_range 1-3 ) MY_PV="${PV//\./_}" MY_PV="${PV%0.0}" MY_PV=$(replace_version_separator 2 'u' $(get_version_component_range 1-3)) MY_PV="${PN}-$(replace_version_separator 2 "-" $MY_PV)" MY_PV=${PV%.?}-${PV##*.} MY_PV=${PV//./_} MY_PV=${PV//.} MY_PV=${PV//\./\-} MY_PV="${PV/_rc/-rc}" MY_PV=${PV/_beta/-b} Thank you for your patience. ;-)
(In reply to Martin Mokrejš from comment #4) > I propose these constructs be explained in that paragraph.: Most of those are basic Bash string substitution operations. Gentoo developers who passed the quiz are supposed to know them by heart :) See http://www.tldp.org/LDP/abs/html/refcards.html#AEN22664 for the syntax. For example, you probably want MY_PV="${PV/_/}" for your mira ebuild: it will turn the "4.0_rc2" ebuild version into the "4.0rc2" PEP-440 version, which you can then use to build the package's source uri and tarball filename.
No progress, closing. Feel free to reopen with a patch attached.
