For alsa-driver-1.0.14_rc2_p3234.ebuild and alsa-headers-1.0.14_rc2_p3234.ebuild the "_p3234" part is invalid for ebuild names IMHO (see http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1#doc_chap2). eix-update stops on those with the error message "Garbage at end of version string: _p3234". Reproducible: Always Steps to Reproduce:
The ebuild name is just fine w/ >=portage-2.1.1; eix is broken. $ emerge -pv alsa-headers These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] media-sound/alsa-headers-1.0.14_rc2_p3234 [1.0.14_rc2] 16,139 kB
Just because portage eats it, does not mean that the version number is fine. In fact, this is an illegal version number according to the versioning scheme on the cited URL which had been used all the time: There is only one _suf{#} allowed. With several suffixes, it is not even clear which should take precedence. Is e.g. 1.0-rc2_rc1 higher or lower than 1.0-rc1? If you really plan to extend the versioning scheme, please document it somewhere so that I can change eix accordingly.
(In reply to comment #2) > If you really plan to extend the versioning scheme, please document it > somewhere so that I can change eix accordingly. We don't plan it, it's been already done since portage 2.1.1 (and please file a separate bug about documentation)
It's not only eix, which is broken then. Package list on gentoo web site is also broken: http://packages.gentoo.org/packages/?category=media-sound;name=alsa-headers If the specification for version numbers has changed, then two new bugs have to be filed for these errors.
In eix svn (eix-0.8.8) I "fixed" it now in the way I understood the new versioning scheme: Multiple suffixes are allowed, earlier suffixes take precedence. Thus, you get the sorting: 1.0_rc1_rc2 1.0_rc1 1.0_rc1_p1 1.0_rc2_rc1 1.0_rc2 1.0 1.0_p1_rc1 1.0_p1 1.0_p1_p1 If nobody knows a contrary interpretation, I will release this version soon.
Closing as "fixed" since eix-0.8.8 is now in the portage tree.
*** Bug 166031 has been marked as a duplicate of this bug. ***
*** Bug 167347 has been marked as a duplicate of this bug. ***