The version number of dev-perl/AnyEvent from the portage is splitted into 4 parts using dots, so eg.: AnyEvent in portage has 5.2.5.1 but on CPAN (aka real version) is 5.251 Reproducible: Always Steps to Reproduce: 1. emerge -pv AnyEvent 2. Go to: http://search.cpan.org/perldoc?AnyEvent 3. Compare versions Is there any particular need of doing this that way? Ebuild needs to have MY_P. It does not work with some kind of "automagic" cpan2ebuild stuff (like CPANPLUS) and even if we assume that this should be "fixed" on CPANPLUS side (afair PortageXS) the logic for checking all possible variants will be complicated.
(In reply to comment #0) > 2. Go to: http://search.cpan.org/perldoc?AnyEvent > 3. Compare versions Why would anyone do that, BTW? Seems odd to install the documentation only to go to the web so to read about it. And check the version..?? (What wasn't working for you, would be my first question. perldoc? terminal emulator?) > Is there any particular need of doing this that way? Yes. Ebuilds have a particular syntax for their names. Try it and see! > Ebuild needs to have MY_P. This is common when the tarball to ebuild has an illegal name for portage w/o massaging. For example, you build the name in parts to reconstruct for ${S}, otherwise, portage doesn't know where to find the tarball it just unpacked. > It does not work with some kind of "automagic" cpan2ebuild stuff (like > CPANPLUS) and even if we assume that this should be "fixed" on CPANPLUS side > (afair PortageXS) the logic for checking all possible variants will be > complicated. > Not sure what you mean by this bit. What does CPANPLUS and PortageXS have to do with it? AFAIK they are only used if you use CPAN to install stuff directly. You are using an ebuild, no? Anyway, inherit versionator is the way to do it in an ebuild, Just had a look, that's what is done. HTH.
(In reply to comment #1) I'm using CPANPLUS CPANPLUS::Dist::Gentoo to generate ebuilds from CPAN, if something is depending on AnyEvent, CPANPLUS (PortageXS) finds that version of AnyEvent on CPAN is 5.251 and same package in portage has version 5.2.5.1 so the do not match... (in fact 5.2.5.1 looks older than the version from CPAN) and instead of using dev-perl/AnyEvent in DEPEND it tries to install/make ebuild of it from CPAN. The example with tarball is not accurate for this case (see: http://search.cpan.org/CPAN/authors/id/M/ML/MLEHMANN/AnyEvent-5.251.tar.gz and it's contents), so ${S} will work without any problems. I found that other perl modules ebuilds with such versions do not have it separated, eg: perl-core/Compress-Raw-Zlib-2.021 dev-perl/Statistics-Descriptive-3.0100 dev-perl/Parse-RecDescent-1.964 dev-perl/POE-1.287 So the question is: is this really needed?
I had another look at this ebuild and it looks like that: MY_P=${PN}-$(get_major_version).$(delete_all_version_separators $(get_after_major_version)) S=${WORKDIR}/${MY_P} So this means (or am I wrong?) that it gets version numbers from the ebuild name, strips all separators (dots) and passes it to ${S} IMHO if the version in ebuild name was changed to the one from CPAN (5.251) those two lines will become obsolete...
This is how package managers compare version numbers: | Version specifications are compared component by component, moving from left | to right. | | The first component of the number part is compared using strict integer | comparison. | | Any subsequent components of the number part are compared as follows: | | * If neither component has a leading zero, components are compared using | strict integer comparison. | | * Otherwise, if a component has a leading zero, any trailing zeroes in that | component are stripped (if this makes the component empty, proceed as if | it were 0 instead), and the components are compared using a stringwise | comparison. | | If one number part is a prefix of the other, then the version with the longer | number part is greater. Note in particular that 1.0 is less than 1.0.0. <http://dev.gentoo.org/~tanderson/pms/eapi-2-approved/pms.html#x1-270002.3> So if upstream (AnyEvent) releases 5.0 5.01 5.1 5.11 5.111 5.112 5.12 5.2 5.201 5.202 5.21 5.25 5.251 we have to do some transformation to tell the package manager how to sort them: - Add additional separators (5.251 -> 5.2.5.1) - Add additional zeros (5.1 -> 5.100) In both cases our version wouldn't match the upstream version.
Ok, I got it. So everything is clear to me now.