| 1 |
I'll start, maybe others will follow. |
| 2 |
|
| 3 |
Installed from the perl-"experimental" overlay. One edit to the ebuild and got perl 5.10.0. |
| 4 |
|
| 5 |
perl-cleaner attempted to re-emerge 5.8. Ouch! '-) |
| 6 |
|
| 7 |
Re-emerged all the perl modules with some shell scripts. (Catalyst worked perfectly, goal acheived.) |
| 8 |
|
| 9 |
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. |
| 10 |
|
| 11 |
Inkscape has a dependency on perl which caused pain, so I found some patches. Works great. Posted ebuilds and patches at b.g.o. |
| 12 |
|
| 13 |
Gnumeric has perl use flag, but no apparent dependency to match. So, seems fine. |
| 14 |
|
| 15 |
I got a random user note on #gentoo-perl: |
| 16 |
|
| 17 |
"I have a problem with compilation net-snmp with Perl support. .) |
| 18 |
Without Perl support all is ok." |
| 19 |
|
| 20 |
Which *seems* to be an upstream problem, unfortunately. Embedded perl 5.10 snmp agent won't work. Building with --disable-embedded-perl works: |
| 21 |
|
| 22 |
EXTRA_ECONF="--disable-embedded-perl" emerge -av net-snmp |
| 23 |
|
| 24 |
... 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.) |
| 25 |
|
| 26 |
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). |
| 27 |
|
| 28 |
There is a very similar bug report so I requested it be reopened, but maybe there is still no maintainer for g-cpan. IDK. |
| 29 |
|
| 30 |
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. |
| 31 |
|
| 32 |
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. |
| 33 |
|
| 34 |
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. |
| 35 |
|
| 36 |
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? '-) |
| 37 |
|
| 38 |
-- Mike Higgins |
Archives