I'll start, maybe others will follow.
Installed from the perl-"experimental" overlay. One edit to the ebuild and got perl 5.10.0.
perl-cleaner attempted to re-emerge 5.8. Ouch! '-)
Re-emerged all the perl modules with some shell scripts. (Catalyst worked perfectly, goal acheived.)
perl-tk needed a version bump, so I posted the ebuild I edited to b.g.o. Apparently the change in maintainer was missed and so too was the version with the needed fixes.
Inkscape has a dependency on perl which caused pain, so I found some patches. Works great. Posted ebuilds and patches at b.g.o.
Gnumeric has perl use flag, but no apparent dependency to match. So, seems fine.
I got a random user note on #gentoo-perl:
"I have a problem with compilation net-snmp with Perl support. .)
Without Perl support all is ok."
Which *seems* to be an upstream problem, unfortunately. Embedded perl 5.10 snmp agent won't work. Building with --disable-embedded-perl works:
EXTRA_ECONF="--disable-embedded-perl" emerge -av net-snmp
... and will build SNMP.pm and related modules. But, obviously, it won't allow an embedded perl agent. I've filed a bug upstream for the embedded fail. (Seems like a header file it finds is broken, but I'm no expert.)
g-cpan is broken too, it seems, with the new perl. Garbage is now added to the workdir variable, so nothing gets built or installed. Doesn't cause emerge to fail, though, which is odd (to say the least).
There is a very similar bug report so I requested it be reopened, but maybe there is still no maintainer for g-cpan. IDK.
As for handling issues like needing 5.8 for a particular package like embedded agent in snmp, perl should be available slotted. IDK (and can't find out, apparently) if that is the plan.
One problem is portage is removing old perl 5.8 modules when emerging new ones. I don't think this is needed, as long as @INC is correct.
Changing /usr/bin/perl to point to the right binary should be all that is needed, IIRC to get back 5.8... Anyway, (from what I know) an eselect perl thingy *should* be dead simple to make this easy for the user.
Well, that's my $.02. What else, then, is keeping perl-5.10.0 out of the tree? Are there really only about five of us who care? '-)
-- Mike Higgins
> One problem is portage is removing old perl
> 5.8 modules when emerging new ones. I don't
> think this is needed, as long as @INC is correct.
Should be built properly via perl's normal make cycle.
Intention is to leave the old library in place to avoid
the user having to-rebuild everything from scratch every
> Changing /usr/bin/perl to point to the right
> binary should be all that is needed, IIRC to
> get back 5.8... Anyway, (from what I know) an
> eselect perl thingy *should* be dead simple to
> make this easy for the user.
Yup: backing off the executable will run a perl with
the older @INC higher up in the versions.
Steven Lembark 85-09 90th St.
Workhorse Computing Woodhaven, NY, 11421
[hidden email] +1 888 359 3508
In reply to this post by perl
I recently used this successfully. The cpan -a (autobundle) seems to be the trick. Then did perl-cleaner
--modules and perl-cleaner --libperl. The only remnant was to change the SHELL environmental var perlhome to point to the new base. emerge seems to use this var with perl packages. Once it was changed my old 5.8.8 packages were not touched by emerge.
Some perl modules are not 100% compatible with 5.10.1, of course. I found perl-info was one. There will be others as I go along, I am sure.
|Free forum by Nabble||Edit this page|