According to the Gentoo Dev Guide, ebuilds are allowed to have a single letter in the base version string (i.e. foo-1.1a). The problem is that portage complains when one attempts to append a valid suffix (i.e. _pre or _beta) to the ebuild's name. It states that a letter cannot precede the " _ ", however the Dev Guide says that a single letter is allowed. The suffix doesn't count towards this single letter, since it isn't part of the base name. I request that portage be repaired to allow this aspect of the naming conventions in ebuilds.
*** Bug 27840 has been marked as a duplicate of this bug. ***
I also encountered the same problem with app-arch/lha. The souce distribution uses "lha-114i-ac20030921" style versioning and I cannot create ebuild named lha-114i.20030921.ebuild (anyhow, it is not a valid name according to Gentoo Policy). How should I name it? Previous release, lha-114i-ac20020903 is in Portage tree but included as lha-114i-r1.ebuild. I think it is worse (-r? is only meant for Gentoo internal release and we should bump -ver or _suf) than lha-114i.20030921.ebuild. However, it seems adding `-r?' is the only way to create such an ebuild (I think it is really bad). Should we allow not only number (and single letter immediately after the last digit) in -ver but also alphabet ? We might exclude alphabet-only version in -ver (e.g. lha-114i.ac.20030903 is invalid since it will be split to `114i', `ac' and `20030903' while we would accept lha-114i.ac20030903 since `114i' and `ac20030903' would be considered as valid versioning according to the suggested naming scheme).
Created attachment 21418 [details, diff] diff to portage-2.0.49-r15
This bug has been already fixed in 2.0.50_pre*
supposed to be fixed in 2.0.50 which is stable now. If this bug is not fixed please reopen.
Looks like it's not working yet... /usr/local/download/portage-cvs/gentoo-x86/net-analyzer/netwatch $ emerge -pv netwatch-1.0b-r3.ebuild These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] net-analyzer/netwatch-1.0b-r3 [empty/missing/bad digest] [1] Total size of downloads: 0 kB Portage overlays: [1] /usr/local/download/portage-cvs/gentoo-x86 /usr/local/download/portage-cvs/gentoo-x86/net-analyzer/netwatch $ emerge -pv netwatch-1.0b_pre3.ebuild These are the packages that I would merge, in order: Calculating dependencies ...done! Traceback (most recent call last): File "/usr/bin/emerge", line 2574, in ? mydepgraph.display(mydepgraph.altlist()) File "/usr/bin/emerge", line 1236, in display if portage.pkgcmp(portage.pkgsplit(x[2]), portage.pkgsplit(myoldbest)) < 0: File "/usr/lib/portage/pym/portage.py", line 2825, in pkgcmp mycmp=vercmp(pkg1[1],pkg2[1]) File "/usr/lib/portage/pym/portage.py", line 2810, in vercmp cmp1=relparse(val1[x]) File "/usr/lib/portage/pym/portage.py", line 2499, in relparse number=string.atof(mynewver[0]) File "/usr/lib/python2.3/string.py", line 205, in atof return _float(s) ValueError: invalid literal for float(): .0b /usr/local/download/portage-cvs/gentoo-x86/net-analyzer/netwatch $ diff -Naur netwatch-1.0b-r3.ebuild netwatch-1.0b_pre3.ebuild --- netwatch-1.0b-r3.ebuild 2004-02-08 19:10:20.000000000 -0800 +++ netwatch-1.0b_pre3.ebuild 2004-02-08 19:06:49.000000000 -0800 @@ -2,7 +2,7 @@ # Distributed under the terms of the GNU General Public License v2 # $Header: $ -MY_P="${PF/-r/.pre}" +MY_P="${P/_pre/.pre}" SRC_URI="http://www.slctech.org/~mackay/${MY_P}.src.tgz" DESCRIPTION="a ncurses based network monitoring program" HOMEPAGE="http://www.slctech.org/~mackay/netwatch.html"
Created attachment 25244 [details, diff] patch to fix the new error in portage-2.0.50 this situation creates an Exception as atof() is called on the part before the underscore (in relparse()).
the patch fixes the problem for me.
*** Bug 41224 has been marked as a duplicate of this bug. ***
also see #37406 for a rewrite of the versioning code that should also fix the problem (as well as several limitations with the current code).
Is it going to be fixed in the next release?
*** Bug 43580 has been marked as a duplicate of this bug. ***
*** Bug 58973 has been marked as a duplicate of this bug. ***
Bug has been fixed and released in stable portages on or before 2.0.51-r2
