Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
Perl 5.10.0 was released about a month ago. I attach modified ebuilds and patches that I used to install it successfully (?) on my system Reproducible: Always
Created an attachment (id=141171) [details] ebuilds and patches for perl and libperl 5.10.0 Tested briefly on my ~x86 system (so platform specific patches for other platforms probably fail.) The source file needs to be fetched and repackaged manually from http://www.perl.org
I installed these ebuilds on a x86 Gentoo, ran perl-cleaner and everything seems to work like a charm. BTW I patched the ebuilds changing the SRC_URI line with: SRC_URI="http://www.cpan.org/src/perl-5.10.0.tar.gz" RESTRICT="nomirror" to avoid the manual download of the Perl package (I know, I should have used the variables, but I was in an hurry to try this ;-)). Well, I hope to see something along the lines of this ebuilds in Portage soon...
Created an attachment (id=141778) [details] New Perl 5.10.0 lib64 patch The included perl-5.10.0-lib64.patch does not apply cleanly on ~amd64. I have attached one that does and seems to work. Reporting on another problem, I got collision protection errors while trying to install dev-lang/perl, as it seems these files/modules: /usr/bin/config_data [dev-perl/module-build-0.28.08] /usr/bin/ptar already [dev-perl/Archive-Tar-1.32] /usr/bin/ptardiff already [dev-perl/Archive-Tar-1.32] have been integrated into the core perl package: http://perldoc.perl.org/perldelta.html#New-modules I am using paludis with the collision-protection hook and not emerge, so this might be the reason nobody else has reported any problems using these new ebuilds. Anyway, now that these modules are already included, shouldn't both dev-perl/module-build and dev-perl/Archive-Tar be blocked in the new perl ebuild?
Thank you for the ebuilds. I installed them on my ~x86 system and after perl-cleaner everything worked with only two modules failing: 1. Math::Pari failed to compile but it was solved by applying the patch from here: http://www.perlmonks.org/?node_id=663706 2. perl-tk-804.027 (the only version in portage) also failed but the latest version from cpan (Tk-804.028) installed with no problems. I am now exploring all the new mouthwatering features of perl 5.10.
dev-perl/Module-CoreList is also included in 5.10 now.
In the perl-experimental overlay! Sorry for keeping you waiting. Please report problems/whatever...
*** Bug 219477 has been marked as a duplicate of this bug. ***
OK, the problems (as of rev.63). First perl: as this is portage-specific, I think MakeMaker-RUNPATH patch is still needed gcc42-command-line patch however, seems to be applied upstream -Dinc_version_list="$inclist" is listed twice -Dlocincpth="/usr/src/linux/include" is something that actually breaks things (net-snmp to be specific) Next libperl: create-libperl-soname patch seems to be still needed (both for qa issue and the fact, that without it libperl.so.1 link is not created) I don't know what is -Dusedevel for, but as it was not in the old ebuild, is probably not needed (seems to work fine without it) more general issues: a few virtuals need to be updated for perl 5.10 (for my perl set it were perl-Digest-MD5 and perl-MIME-Base64) I temporarily solved dev-perl/module-build and dev-perl/Archive-Tar problem via 'scrollkeeper-9999 route' but actual fix would be done by editing their revdeps it seems that perl-cleaner somehow got dependencies for dev-perl/XML-LibXML wrong, cause it was trying to emerge it before dev-perl/XML-LibXML-Common, it resulted in some warnings, it did merge, but to be safe I re-emerge'd it after emerging dev-perl/XML-LibXML-Common I think that's all.
Hi! Just to report that perl-5.10 for perl-experimental overlay works fine (I'm on AMD64), so it would be time to go into Portage. ;) Some virtual/* packages need to be fixed before, however.
I try today perl-experimental on my amd64 but no luck :( ... >>> sys-devel/libperl-5.10.0 merged. >>> Emerging (2 of 2) dev-lang/perl-5.10.0 to / * perl-5.10.0.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking perl-5.10.0.tar.gz ;-) ... [ ok ] * PLEASE NOTE: You are compiling perl-5.10.0 with * interpreter-level threading enabled. * Threading is not supported by all applications * that compile against perl. You use threading at * your own discretion. >>> Unpacking source... >>> Unpacking perl-5.10.0.tar.gz to /var/tmp/portage/dev-lang/perl-5.10.0/work * Applying perl-prelink-lpthread.patch ... [ ok ] * Applying perl-picdl.patch ... [ ok ] * Applying perl-5.10.0-regexp-nossp.patch ... [ ok ] * Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is: * * /usr/portage/local/layman/perl-experimental/dev-lang/perl/files/perl-5.10.0-gcc42-command-line.patch * ( perl-5.10.0-gcc42-command-line.patch ) Can't see this patch even at http://overlays.gentoo.org/proj/perl/browser/perl-experimental/dev-lang/perl/files
I've upgraded and re-installed all my modules - everything went smoothly except that I had to bump dev-perl/math-pari to 2.010800 because 2.010709 failed compilation (just changing ebuild name worked) - Should I raise a separate bump request bug which blocks this one? Sergiy: I got that error when I first attempted to install 5.10, as far as I can tell this patch is not needed for 5.10.0, I'm guessing it's a hangover from the 5.8 ebuild - I commented out the line in the ebuild and everything worked fine.
ok I already install fine under ~amd64 but have same problem as http://bugs.gentoo.org/show_bug.cgi?id=224577 and also for me some collision with dev-perl/module-build-0.28.08 and dev-perl/Archive-Tar-1.38
(In reply to comment #8) > as this is portage-specific, I think MakeMaker-RUNPATH patch is still needed it also still applies fine > gcc42-command-line patch however, seems to be applied upstream compiles fine with gcc 4.2.1 > -Dinc_version_list="$inclist" is listed twice I removed one in my local copy > -Dlocincpth="/usr/src/linux/include" is something that actually breaks things > (net-snmp to be specific) Not sure why this was added, but I'd like it to be removed if possible. > Next libperl: > create-libperl-soname patch seems to be still needed (both for qa issue and the > fact, that without it libperl.so.1 link is not created) that is important indeed. > I don't know what is -Dusedevel for, but as it was not in the old ebuild, is > probably not needed (seems to work fine without it) I removed it in my local copy as well. > more general issues: > a few virtuals need to be updated for perl 5.10 (for my perl set it were > perl-Digest-MD5 and perl-MIME-Base64) virtual/perl-Digest-MD5 virtual/perl-MIME-Base64 virtual/perl-Scalar-List-Utils all have ebuilds pointing to ~dev-lang/perl-5.8.8, which probably should be >=dev-lang/perl-5.8.8
@perl-team: what can I do to help? I have it all working, patches ported, etc. in the prefix overlay.
Please note the following security issue that affects Perl 5.10 only: http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-2827 Find a patch at the referenced Debian bug, or in the upstream bug. Do not commit Perl 5.10 to the tree without including this patch, or bump to a version that ships this patch.
rbu, thanks. For grabs: http://overlays.gentoo.org/proj/alt/changeset/26266
Well, just wanted to report that update to perl-5.10 is not so smooth as I wanted that. At least after attempt to make emerge emerge @preserved-rebuild I've got vim fail with the following error: vim: symbol lookup error: vim: undefined symbol: PL_unitcheckav Also notice: http://developer.pidgin.im/ticket/5137 And this mail tells us about problems with the same symbol: http://www.nntp.perl.org/group/perl.xs/2008/03/msg2443.html So seems that there is some API change which could case breakage of existing packages. And yes, this should not stop from bumping perl at least hardmasked :) Now I've revert back perl to 5.8 but continue investigations of vim issue in my unstable chroot.
Also IMHO better to rename "perl-5.10.0*" to "perl-5.100*"
(In reply to comment #18) > Also IMHO better to rename "perl-5.10.0*" to "perl-5.100*" > I would imagine this should be something slotted as perl-5.100 doesn't really make sense and would cause confusion since it's not similar to upstream's versioning scheme.
Perl 5.10 has been out for more than 300 days... Why is it not possible to put it in portage, at least hard-masked?
(In reply to comment #20) > Perl 5.10 has been out for more than 300 days... Why is it not possible to put > it in portage, at least hard-masked? > Seems that maintainers are already working on this, simply look to recent changes in tree with some perl modules like: http://sources.gentoo.org/viewcvs.py/gentoo-x86/virtual/perl-IO-Compress-Zlib/ChangeLog?view=markup :-)
(In reply to comment #21) Oh, sorry, I was too hurry :D . I didn't check the recent changes. Thanks.
yet it's still not even hard masked....
By the way, perl-5.8 is being end-of-lifed. http://aspn.activestate.com/ASPN/Mail/Message/perl5-porters/3675589
What is the hold up exactly? Why did this go into the perl overlay and not hard-masked in ~arch? There are 62 distributions listed on DistroWatch that ship perl-5.10, including Slackware! http://distrowatch.com/search.php?pkg=perl&pkgver=5.10.0#pkgsearch Can someone just move this to ~arch and mask it already?
The version in Portage, Perl 5.8.8, is now replaced by the 5.8.9, which is essentially a fix version. When will we get Perl 5.10 in Portage :/ ? It has been out for a year!
> The version in Portage, Perl 5.8.8, is now replaced by the 5.8.9, > which is > essentially a fix version. > When will we get Perl 5.10 in Portage :/ ? It has > been out for a year! From what I've been told, we could be the only folks who care about it, so there is no urgency. I'd like to think that's not the case, but have to believe it is so -- barring evidence presented to the contrary. :(
Well, I gave it a shot. Fixed ebuild to remove call to non-existing command-line patch file. Emerged. Ran perl-cleaner modules. Next thing I see, it downgraded perl to 5.8.8. :( Found several things in /var/db/pkg that were dev-perl but should be perl-core. DK what that's about or how to fix. Just removed them. I'll mask "<dev-lang/perl-5.10.0", hopefully that will show me the problem before wasting more cpu cycles downgrading. How can perl-cleaner EVER do that????
(In reply to comment #28) > Well, I gave it a shot. Fixed ebuild to remove call to non-existing > command-line patch file. Emerged. > > Ran perl-cleaner modules. Next thing I see, it downgraded perl to 5.8.8. :( > > Found several things in /var/db/pkg that were dev-perl but should be perl-core. > DK what that's about or how to fix. Just removed them. > > I'll mask "<dev-lang/perl-5.10.0", hopefully that will show me the problem > before wasting more cpu cycles downgrading. How can perl-cleaner EVER do > that???? > I have been using perl 5.10.0 for a year now, with the same ebuild I submitted here. I witnessed no problems. I don't think I ran perl-cleaner. If you would like to re-install all your modules for perl 5.10.0, this can be done as follows: 1. Before installing the new perl, run (as root) perl -MCPAN -e 'autobundle' it will say something like Wrote bundle file: /root/.cpan/Bundle/Snapshot_XXX.pm 2. install the new perl 3. run (as root) perl -MCPAN -e 'install Bundle::Snapshot_XXX' (where the name is from step 1)
> I have been using perl 5.10.0 for a year now, with the same > ebuild I submitted here. I witnessed no problems. Great. Can we get it in the "stable" tree, already? '-) For me, it's not really the point to use CPAN tools. Rather, it's how to use Gentoo ebuilds and scripts to manage perl modules. I rebuilt everything found with some bash and stuff against this code from perl-cleaner: (PKGDIR=$(/usr/bin/portageq vdb_path) ; for checkfile in `find $PKGDIR -maxdepth 3 -mindepth 3 -name "CONTENTS" and re-emerged all the ebuilds with -1, which nicely rebuilt them in 5.10 and removed them from 5.8. One failed: perl-Tk. I'll be curious to see if it still works. No. Needs a version bump. Has a new maintainer... I'll file elsewhere for that. http://www.perlmonks.org/?node_id=657846 http://search.cpan.org/~srezic/Tk-804.028/ Inkscape also failed to build (trying snapshot now). https://bugs.launchpad.net/inkscape/+bug/262877 And finally I needed four items w/o ebuilds in the gentoo tree or perl-"experimental" overlay: perl-gcpan/Authen-Simple-Net perl-gcpan/Authen-Simple-SSH perl-gcpan/Catalyst-Authentication-Credential-Authen-Simple perl-gcpan/Catalyst-Plugin-Session-Store-DBI ... and now my catalyst application is working again. ;-) So, it looks to me like the ebuild in perl-"experimental" works (with one edit), then it is simply a matter of looking for some obvious problems (like dev-perl module installed is now in perl-core, for example, or mysteriously masked installed modules... and rebuilding all the modules. It's a one-way thing, then. Or, it's to be slotted? And things built against perl can be rebuilt, maybe a working perl-cleaner? ISTR that two perls can co-exist easily enough... it's usually called by the symlink anyway. It would be great if this gets into the tree before 5.10.1 is released, IMO... so we can see if we hit any new perl bugs, no? ;-) Seriously, there are new features, it seems stable enough for ~arch anyway, (from what little I know about it). Anyway, it can't be *that* much to do to try to ease the upgrade for everyone, if I can do it here... '-) For my part, I have three other machines I'd bring up to date, perl-wise, ready to test any new ebuilds or helper scripts.
(In reply to comment #30) (postscript) > > One failed: perl-Tk. I'll be curious to see if it still works. No. Needs a > version bump. Has a new maintainer... I'll file elsewhere for that. Updated ebuild # Copyright 1999-2007 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/dev-perl/perl-tk/perl-tk-804.028.ebuild,v 1.25 2007/07/22 07:49:00 graaff Exp $ inherit perl-module eutils multilib MY_P=Tk-${PV} S=${WORKDIR}/${MY_P} DESCRIPTION="A Perl Module for Tk" HOMEPAGE="http://search.cpan.org/~ni-s/" SRC_URI="mirror://cpan/authors/id/S/SR/SREZIC/${MY_P}.tar.gz" LICENSE="Artistic" SLOT="0" KEYWORDS="alpha amd64 arm hppa ia64 mips ppc ppc64 sh sparc x86 ~x86-fbsd" IUSE="" DEPEND="x11-libs/libX11 dev-lang/perl" myconf="-I/usr/include/ -l/usr/$(get_libdir)" mydoc="ToDo VERSIONS" export X11ROOT=/usr src_unpack() { unpack ${A} cd ${S} epatch ${FILESDIR}/xorg.patch } Seems to work perfectly. > > Inkscape also failed to build (trying snapshot now). > https://bugs.launchpad.net/inkscape/+bug/262877 Snapshot compiles just fine. New dependency on sci-libs/gsl. The patch can be, would have to be?, backported, as they don't yet have a new stable release. Now, can I really file bugs against these packages before 5.10.0 is even in the gentoo tree? '-)
Being released for a year sounds fairly stable enough to finally be in ~arch already. Submit this to ~arch, and file bugs against the broken ebuild/modules. I'm not sure why this has sat in the overlay for so long when there are no blockers. 5.8.8 has been EOL, so this needs to go into portage already.
> 5.8.8 has been EOL, so this needs to go into portage already. As a matter of fact, 5.8.9 was released: http://search.cpan.org/~nwclark/perl-5.8.9/pod/perl589delta.pod There's nothing really significant changed here, as the 5.8.x branch is EOL: "We have only limited volunteer labour, and the maintenance burden is getting increasingly complex. Hence this will be the last significant release of the 5.8.x series. Any future releases of 5.8.x will likely only be to deal with security issues, and platform build failures. Hence you should look to migrating to 5.10.x, if you have not started already. Alternatively, if business requirements constrain you to continue to use 5.8.x, you may wish to consider commercial support from firms such as ActiveState."
(In reply to comment #29) > I have been using perl 5.10.0 for a year now, with the same ebuild I submitted > here. I witnessed no problems. I don't think I ran perl-cleaner. If you would Too dangerous. I am downgrading it now. Once, after near year of good life, I start to have strange text bugs (strange text inclusions, unstable XML::Parser::Lite results, but no direct failures) in my perl-generated site.
> > Too dangerous. I am downgrading it now. Once, after near year of good life, I > start to have strange text bugs (strange text inclusions, unstable > XML::Parser::Lite results, but no direct failures) in my perl-generated site. > Wow, this is truly a blanket statement without any support to it. What did you do to find out where the problem really is? Like, what version of SOAP::Lite are you using? (0.710.08 is the latest.) So, are you using that version? Do you have any links to bug reports for 5.10 breaking the version you do use? Are you sure what you are seeing is not an edge case for something now appearing in your XML that didn't before? Did you file a bug report against SOAP::Lite to see what they say, before you blame the latest version of perl? (Anyway, barring any supporting documents or evidenced efforts, this only looks like spreading FUD.) For my FUD, I was reading the debian perl devs discussion about this... from FEBRUARY... BUT, I have *yet* to see WORD *ONE* from the gentoo perl devs (is there really such a team after all? Maybe one of them could join the discussion and put some fears and uncertainty to doubtless rest?).
removed gcc42-command-line patch from ebuild. during perls build I get the following error. make[1]: Leaving directory `/var/tmp/portage/dev-lang/perl-5.10.0/work/perl-5.10.0' /var/tmp/portage/dev-lang/perl-5.10.0/temp/environment: line 2605: TODO:: command not found * Applying perl-h2ph-ansi-header.patch ... [ ok ] require '_h2ph_pre.ph'; no warnings 'redefine'; 1; !!! dosed: /var/tmp/portage/dev-lang/perl-5.10.0/image/usr/lib64/perl5/5.10.0/ExtUtils/xsubpp does not exist chmod: cannot access `/var/tmp/portage/dev-lang/perl-5.10.0/image//usr/lib64/perl5/5.10.0/ExtUtils/xsubpp': No such file or directory
perl-5.10.0 doesn't work well with the Gentoo tree (yet), so you're better off not using it.
(In reply to comment #37) > perl-5.10.0 doesn't work well with the Gentoo tree (yet), so you're better off > not using it. > When? I hope they include it in 2009.0. Seems ridiculous not to.
There will not be 2009.0 at all read Gentoo.org new for more info.
(In reply to comment #37) > perl-5.10.0 doesn't work well with the Gentoo tree (yet), so you're better off > not using it. > What reason or justification do you have for thinking that perl-5.10.0 doesn't work with Gentoo? This sounds like an unsubstantiated claim with no proof or evidence. If it does in fact not work with Gentoo, then file the bugs, and mark them as deps so that Gentoo can finally get with the program. Otherwise, the current version of perl has been EOL and will no longer be supported. In fact, the 5.8.x branch has been EOL entirely. It's time any issues with 5.10 be resolved already (perhaps we should stop making ebuilds for CPAN modules already when CPAN can do all of the downloading, building, and installing for us). Slackware 12.2 beat Gentoo to the punch (generally considered the most stable distro). This bug has 60 votes already. There's no reason this shouldn't at least be masked until any blockers are fixed.
This really is getting nuts. I'm running 5.10 on all my other distros, plus Windows (Cygwin and ActiveState both). There's no excuse for Gentoo to be this far behind. Is dev-lang/perl unmaintained now?
(In reply to comment #40) > (In reply to comment #37) > > perl-5.10.0 doesn't work well with the Gentoo tree (yet), so you're better off > > not using it. > > What reason or justification do you have for thinking that perl-5.10.0 doesn't > work with Gentoo? This sounds like an unsubstantiated claim with no proof or > evidence. chilllllll! I tried it out on my own in Prefix and came to the conclusion that not all deps aren't ready for it yet. I've seen changes in gentoo-x86 that appear like preparations to make it work. So far my claim, with proof being two of my systems which I had to revert back to 5.8 with some qfile | grep | cut | xargs emerge magic. > If it does in fact not work with Gentoo, then file the bugs, and mark them as > deps so that Gentoo can finally get with the program. Otherwise, the current > version of perl has been EOL and will no longer be supported. In fact, the > 5.8.x branch has been EOL entirely. It's time any issues with 5.10 be resolved > already (perhaps we should stop making ebuilds for CPAN modules already when > CPAN can do all of the downloading, building, and installing for us). I'm not on the perl team, and I can't look in their agenda, but I do know it takes more than just shoving the ebuild into the tree. (learnt it the hard way) > Slackware 12.2 beat Gentoo to the punch (generally considered the most stable > distro). This bug has 60 votes already. There's no reason this shouldn't at > least be masked until any blockers are fixed. Comments like these will get you nowhere.
(In reply to comment #42) > (In reply to comment #40) > > (In reply to comment #37) > > > perl-5.10.0 doesn't work well with the Gentoo tree (yet), so you're better off > > > not using it. > > > > What reason or justification do you have for thinking that perl-5.10.0 doesn't > > work with Gentoo? This sounds like an unsubstantiated claim with no proof or > > evidence. > > chilllllll! > > I tried it out on my own in Prefix and came to the conclusion that not all deps > aren't ready for it yet. I've seen changes in gentoo-x86 that appear like > preparations to make it work. So far my claim, with proof being two of my > systems which I had to revert back to 5.8 with some qfile | grep | cut | xargs > emerge magic. If you know of bugs and issues, file them and mark them as deps. Otherwise, stop claiming there are problems when you can't back it up (that's what makes it unsubstantiated).
Jason, if there is no problems why still this bug is still here? So stop claiming that there is no problems because it is pure absurd. --- At all time to stop offtopics and concentrate to fixing problems. How I can help to fix this bug?
Hey! We are all friends here and we love Gentoo. If perl-5.10 is not in the main tree yet I m sure it has to be some valid reason. I am using 5.10 for nearly a year (see Comment #4) With the exception of Inkskape (which is now fixed) I have found no other problems since then. Instead of arguing about irrelevancies we should try and help the dev boys to iron out problems by filling bug reports and reporting any solutions that we find ourselves.
(In reply to comment #45) > Hey! We are all friends here and we love Gentoo. > > If perl-5.10 is not in the main tree yet I m sure it has to be some valid > reason. > > I am using 5.10 for nearly a year (see Comment #4) With the exception of > Inkskape (which is now fixed) I have found no other problems since then. > > Instead of arguing about irrelevancies we should try and help the dev boys to > iron out problems by filling bug reports and reporting any solutions that we > find ourselves. > I didn't mean for that to come across hostile. I was not claiming there were no problems, just expecting bugs to be filed when someone claims it doesn't work. I was also getting frustrated with a complete lack of input from the devs as well. My apologies for the way I expressed myself. I will install the version on portage tonight and see how it works with everything. I will also report any bugs I find as well. I will also install ~x86 on a VM and see how well that works (running ~amd64 here). I think we can all help best by installing the version in the perl overlay and reporting all bugs and issues we discover, making sure to mention that it is related to perl 5.10.
yah I have a problem, I can't get the ebuild to build on amd64. I don't know if there are actual problems when running 5.10.0 but the ebuilds need to work so testing can commence.
(In reply to comment #47) > yah I have a problem, I can't get the ebuild to build on amd64. I don't know if > there are actual problems when running 5.10.0 but the ebuilds need to work so > testing can commence. > Can you be more specific? What exactly is not working? Can you post/attach the build log?
(In reply to comment #10) > I try today perl-experimental on my amd64 > > but no luck :( > > ... > >>> sys-devel/libperl-5.10.0 merged. > > >>> Emerging (2 of 2) dev-lang/perl-5.10.0 to / > * perl-5.10.0.tar.gz RMD160 SHA1 SHA256 size ;-) ... > [ ok ] > * checking ebuild checksums ;-) ... > [ ok ] > * checking auxfile checksums ;-) ... > [ ok ] > * checking miscfile checksums ;-) ... > [ ok ] > * checking perl-5.10.0.tar.gz ;-) ... > [ ok ] > * PLEASE NOTE: You are compiling perl-5.10.0 with > * interpreter-level threading enabled. > * Threading is not supported by all applications > * that compile against perl. You use threading at > * your own discretion. > >>> Unpacking source... > >>> Unpacking perl-5.10.0.tar.gz to /var/tmp/portage/dev-lang/perl-5.10.0/work > * Applying perl-prelink-lpthread.patch ... > [ ok ] > * Applying perl-picdl.patch ... > [ ok ] > * Applying perl-5.10.0-regexp-nossp.patch ... > [ ok ] > > * Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is: > * > * > /usr/portage/local/layman/perl-experimental/dev-lang/perl/files/perl-5.10.0-gcc42-command-line.patch > * ( perl-5.10.0-gcc42-command-line.patch ) > > > Can't see this patch even at > http://overlays.gentoo.org/proj/perl/browser/perl-experimental/dev-lang/perl/files > This patch doesn't seem to exist as far as I can tell. I Googled around and can't find it anywhere, so I removed the line and everything compiled (see the attached patch). There are collisions, so I'll file separate bugs for those issues.
Created an attachment (id=176799) [details] Removes the gcc-4.2 patch that doesn't exist. Seems to build on ~amd64 without the patch.
There are 2 collisions: Module::Build and Archive::Tar are now included. Remove these and the build successfully installed on ~amd64. I received a warning about needing to run perl-cleaner, so I'm doing that now. I will test those applications individually. I cannot update the dependencies, but here are the associated bugs: b.g.o. 253050 b.g.o. 253052
Looks like something happened to XML::Parser. I re-emerged dev-perl/XML-Parser and everything seems okay. Not sure what to file that against.
(In reply to comment #48) > Can you be more specific? What exactly is not working? Can you post/attach the > build log? the errors are in comment #36
(In reply to comment #27) > > The version in Portage, Perl 5.8.8, is now replaced by the 5.8.9, > > which is > > essentially a fix version. > > When will we get Perl 5.10 in Portage :/ ? It has > > been out for a year! > > From what I've been told, we could be the only folks who care about it, so > there is no urgency. I'd like to think that's not the case, but have to believe > it is so -- barring evidence presented to the contrary. :( Well 5.10.0 still messes up lvalues in the debugger, which is quite a pain when you're code relies on it. However 5.8.9, fixed that http://search.cpan.org/~nwclark/perl-5.8.9/pod/perl589delta.pod and in general it's just gonna be bug fixes and maintenance stuff so why not make it the default at least?
> Well 5.10.0 still messes up lvalues in the debugger, which is quite a pain when > you're code relies on it. However 5.8.9, fixed that > http://search.cpan.org/~nwclark/perl-5.8.9/pod/perl589delta.pod > and in general it's just gonna be bug fixes and maintenance stuff so why not > make it the default at least? > It's just lvalue subs, which has been fixed upstream but not in 5.10.0 due to a code freeze: http://rt.perl.org/rt3/Ticket/Display.html?id=7013 That bug is fairly old and has a long history (someone in the ticket comments confirmed it for 5.8.8, which is the stable in Gentoo). I think this is a non-issue. And actually, the entire 5.8.x branch has been EOL due to a lack of man-power. Moving to 5.8.9 would be pushing back the inevitable anyways: http://search.cpan.org/~nwclark/perl-5.8.9/pod/perl589delta.pod#Known_Problems
(In reply to comment #53) > (In reply to comment #48) > > > Can you be more specific? What exactly is not working? Can you post/attach the > > build log? > > the errors are in comment #36 > Comment out line 282 in the ebuild (and redo the manifest); looks like a TODO comment that was missed.
(In reply to comment #56) > (In reply to comment #53) > > (In reply to comment #48) > > > > > Can you be more specific? What exactly is not working? Can you post/attach the > > > build log? > > > > the errors are in comment #36 > > > > Comment out line 282 in the ebuild (and redo the manifest); looks like a TODO > comment that was missed. > Resync, this issue has been resolved as of r230 of dev-lang/perl-5.10.0.
Created an attachment (id=177084) [details] build.log had a problem when attempting to build dev-lang/perl with userpriv usersandbox. attached is the build log, removing those resolved the issue.
I installed =dev-lang/perl-5.10.0 from the overlay and rebuilt every package already installed on my system without issue. So far I haven't seen any issues crop up; parrot svn still builds and works fine as well.
virtual/perl-MIME-Base64 depends on perl 5.8 ...
perl-cleaner didn't find half of what needed rebuilding... this one liner should help with things that need to be rebuilt although I don't verify 100% and updatedb should be run first. locate 5.8.8 | grep ^/usr/ | grep -v ^/usr/portage | xargs equery belongs | uniq | sed -e s/^/\=/ | xargs emerge --oneshot
(In reply to comment #60) > virtual/perl-MIME-Base64 depends on perl 5.8 ... There were 1 or 2 packages I resolved by just re-emerging them; this may have been one of them. If one doesn't exist already, can you file a bug report? (In reply to comment #61) > perl-cleaner didn't find half of what needed rebuilding... this one liner > should help with things that need to be rebuilt although I don't verify 100% > and updatedb should be run first. Yes, I did something similar. I found perl-cleaner to not really clean anything, but wrote a 1-liner using perl instead of sed. It seemed more fitting. Thanks for running through the process to help identify any problems.
check out bug #253904 for more info on perl-MIME-Base64
Ok, so Perl 5.10 has been out for almost *five hundreds* days, *sixteen months*, and it isn't in the portage tree, even hard masked. Even worse, no devs posted here. Perl 5.8.8 is officially deprecated. Almost every distro and OS has Perl 5.10. The perl-MIME-Base64 bug has been resolved. Can someone please do something?
I suggest pulling in the "perl-experimental" overlay, which contains dev-lang/perl-5.10.0-r1 and sys-devel/libperl-5.10.0, and help testing those for inclusion in mainline. This is probably especially true if you depend on Perl 5.10 and have a lot of software to test against it.
(In reply to comment #65) That's what I did, and I found no bugs. I didn't test them deeply, though.
I have had a perl dev environment set up around 5.10 since the ebuild first appeared in perl-experimental, I have a large percentage of the CPAN installed through gentoo-portage, perl-experimental and a large local overlay and I have only had one problem where perl 5.10 was a suspect (dev-perl/math-pari mentioned earlier). However, I am on very unexotic hardware (x86) and I realise that one person's anecdotes aren't particularly helpful. I would like to help in any way I can to get this into portage though, but I'm not sure where to start - I can't find any open perl 5.10 related bugs on bugzilla that have outstanding issues (I may be searching wrong, pointers welcome). Is there any official position on the hold up? or rather, where is the finish line on this?
only bug I'm aware of is inkscape, and the maintainer refuses to fix until perl-5.10 is in tree. there are some bugs in the ebuild in stage 1/2 I've heard... but shoudn't affect people not building stages.
what is necessary to put the perl-5.10 in portage tree?
> what is necessary to put the perl-5.10 in portage tree Maintainers. There are two devs formally listed in the perl herd, one of whom has issued 2 commits throughout the entirety of 2008 in the dev-perl namespace (none this year), and the other who has made 5 in 2008 and one this year. The most recent modification made to the dev-lang/perl ebuild by either party was in October 2007. The list of other developers that have contributed recently is varied, with work on the perl package itself largely coming from Torsten (who isn't even in the herd). I'm not denigrating the work that either of these people - or anyone else - has done. No doubt they've done sterling work. The point is that, surely, the recurring incidents where entire herds drift into inactivity and nobody recognises that there is a staffing requirement in order to keep things ticking along smoothly is the fundamental issue here. And it's one that nobody seems to want to talk about. This is exactly how I see things going wrong: 1) A situation develops where the developers who have assumed responsibility for the package(s) at large are either unable - or unwilling - to continue working on it, but remain the sole members of the herd. The reasons for this situation arising can be varied (people become busy with real life, departure of prior talent, poor staffing process/management), but the point is, it can and does happen. 2) Thus, the maintenance of said packages is handled on an ad-hoc basis for a protracted period of time by random developers who perhaps have to in order to satisfy other bugs, or have a passing interest in their continued health. 3) Eventually, a situation arises which really requires a concerted effort by an active and concerned maintainer/herd (say, handling a major new release of perl). At that point the lack of maintainership starts to make itself clear to a larger number of concerned parties/stakeholders. 4) Cue aging unresolved bugs and bugs such as this one. Stakeholders among the userbase (for example, those who use perl in production and care a lot about the distro at large) either (a) voice increasing frustrations (b) continually ask questions about how things can be moved along which, naturally, remain unanswered ... or both. Developers either don't respond or respond in indignation, taking the time to explain to the user who voicing their frustrations doesn't help change anything not addressing the concerns that are being raised, nor opining on how things can actually be moved forwards. And, lo, it continues in ever decreasing circles. Now, I can see it from both sides: As a developer: one doesn't typically like to read criticism of a project that they volunteer free time to, which is understandable. Yes, it stings. However, they are not always mindful that Gentoo has many experienced users, proxy maintainers and the like who also volunteer large amounts of free time to the project. Furthermore, criticism _does_ work (how on earth can a faulty process be improved if it is not subject to criticism?). In fact, I've galvanised one or two bugs in the past myself through immediate and 'careful criticism'. As a user: there are few things more frustrating than being in a position to help - or already being a resourceful and active contributor - and watching one's own efforts to constructively move things forwards fall flat on the floor. In my own experience that usually either results in a reduced level of energy/enthusisam and fewer contributions as a whole and/or the frustrations being voiced in no uncertain terms. I've been there myself and have seen it happen on many bugs lately. As a long-term user and contributor, and a Perl programmer, I care a lot about Gentoo and Perl. However, I'm not going to pretend that I am in a position to spend a lot of time on it because I don't have that time to spend right now; like anyone, I have to pick and choose the things I work on (and right now asterisk is top of the heap). Now, if I were a developer and found myself in such a position, I think that I would communicate that to the project in some fashion which ensured that whatever actions were needed to ensure that the herd was functional and that the quality of maintainership remained at its highest level were taken. I would also seek to leverage the value of concerned and capable users to the maximum extent in order to reduce some of the burdens inherent in that process (perhaps even seek to recruit them if they exhibited the pre-requisite technical talent, work ethic and degree of trustworthiness). The value of such users cannot be overestimated; without naming any names, I've seen at least one top-level project pretty much saved by identifying a 'quality' user, elevating him to the mantle of developer and having him backed up by a few high-quality proxy developers and contributors. Not only that, users were instrumental in expressing the degree of concern which helped to galvanise this transformation and frequently helped to maintain things when the few developers there were were snowed under. At least this project was able to belatedly come to the conlusion that it had a requirement and pull its collective head out of the sand ... But is this a typical story? No, I think not. Bottom line: the fate of perl ultimately rests with the herd (unless it formally becomes a QA problem and heaven forbid that it gets that out of hand). If the herd is not in a position to assume that responsibility - for whatever reason - then the problem should at least be recognised and, ideally, people should be brought on that can. Further, if the prcoedures are not in place in order to do exactly that, then things will probably continue as they are or simply get worse. My two pence, take it or leave it.
(In reply to comment #70) > > what is necessary to put the perl-5.10 in portage tree > > Maintainers. Thanks kerframil for a thorough and succinct summation of the problem. I can see from the deluge of replies that this is a burning issue for all. More than the problem with perl "herd" not existing (or doing much), is the problem with the way things are being handled now. Not to disparage the work so far, but rather to say, there *has* to be a better way. I'm sick to death of every emerge showing with a blocking perl module, needing my input to update the system/world. Gcpan is no good for perl-5.10. The code itself is such a mess no one in their right mind would touch it. Now, WHO IS GOING TO LEAD THE CHARGE TO FIND THE BETTER WAY? For my input, I think a tarball with a one-to-one set of ebuilds for any and all CPAN modules is the only rational way to approach. One update, all PERL<->GENTOO in one place... run a deptree routine that pulls a set and dumps those ebuilds into personal overlay, emerge. Goodbye "perl-experimental". "dev-perl/epan"? There is a module for determining CORE modules for a particular perl version and it seems to work. It *should* be all that's needed to do the rest from metadata (or the Makefile.PL) in the CPAN distro. Whatever fails that, needs some love from a dev. I ran some numbers, it's like a small percentage. IOW, most modules' ebuilds can be magically generated from data provided by CPAN. Anyway, I'm convinced that the current tweaking and twiddling is just causing more pain for the amount of work involved. Rather, rethinking and redesigning the system is in order (and very overdue). That's my untested opinion. But without *any* leaders, this discussion cannot happen. I mean, not the "herd", nor Tove ("the ONE perl dev, in fact, not in name") can even be bothered to reply here?!? That's a pretty clear message, IMO: If you use perl, DON'T USE GENTOO. I mean, you ever mention the distro on a perl support list/IRC/forum..?? They laugh at you for your folly. Can't we *FIX* this, already? Or escalate it so that someone does SOMETHING? > Bottom line: the fate of perl ultimately rests with the herd (unless > it formally becomes a QA problem and heaven forbid that it gets that > out of hand). For my part, I similarly identified the problem months ago: http://bugs.gentoo.org/253279 <quote> ------- Comment #6 From Christian Hartmann 2009-01-02 08:23:55 0000 ------- Right. We're understaffed. - If you're interested in helping out poke me on irc.freenode.net (ian). </quote> ... anyway, I'm less interested in "helping out" at this point than in examining and critiquing THE PLAN (which, as far as I can tell, is non-existent) for getting the Gentoo and perl problem fixed. Then I'd decide if I want to help further a good plan, or continue to find ways to work around the current mess. (And IRC, helpful though it can be in a pinch, provides nothing permanent nor any structure to facilitate a meaningful discussion. It is useless for documentation purposes.) I mean, like, perl was *designed* to have multiple versions on a system..?? What is the *problem*, then, that 5.10 isn't in the tree? It really is *that* basic. It's as if no one understands... "eselect perl version...?? Perl modules are SMALL, who CARES if there are multiple installations? (I'll stop now, as I feel a rant about to happen.) Anyway, if the lone perl HERDSTER needs help, there are plenty of user lists and forums on which to solicit some help. Anyone who actually uses perl to program beyond "hello world" surely can be considered capable of handling stupid ebuilds, no? And the perl.eclass work done makes it even stupider easy, great. If there was a plan, maybe folks would pick what they want to do to help. But there isn't. Since this is an issue that remains completely unresolved for more than six months, can't someone please initiate a QA process unless the HERD publishes a PLAN? <wipes froth from lips> Anyway, as I already gave my $.02 a few times on this, not sure what to call this. Y'all can feel free to ignore, I guess... you're all *volunteers*, right? So are the local firefighters... just saying. I assume no need to flesh out the analogy?
Hm. In portage? In a year+ after adding...
(In reply to comment #71) > (In reply to comment #70) > > > what is necessary to put the perl-5.10 in portage tree > > > > Maintainers. > I mean, like, perl was *designed* to have multiple versions on a system..?? > What is the *problem*, then, that 5.10 isn't in the tree? It really is *that* > basic. It's as if no one understands... "eselect perl version...?? Perl modules The problem as I see it is that Perl installations are supposed to be done by Perl. And unlike everything built with C/C++, where it is assumed you will already have the dependency and you'll do it yourself ( which is very handy to automate by a package manager ), dependencies are managed by Perl, downloaded, and installed, by Perl. Some of these, joyously, are automated by the packages themselves, some require user input to divine dependencies, some execute Perl code to divine dependencies, etc. This is not plausible to automate at present. Suggesting it is possible to automate this, is on par with suggesting ebuilds can be accurately generated by downloading any package off the internet, and parsing its Makefile. This is just *one* lovely hurdle, and imho, despite this, Modules in tree are respectably up-to-date, which isn't bad considering the release schedule of Perl modules in my experience is much more rapid than that of C/C++ based stuff, often multiple releases in a week. Another joyous thing to divine is that of what information *is* discernable by automated tasks, the dependancy information is represented in terms of Modules, not distributions, and as ebuilds map to distributions, and ebuilds don't contain any metadata about what modules they provide, automating dependencies is yet more complicated again. And to add insult to injury, you have "Dual Life" to deal with, and Dual Life changes between successive Perl versions, so if you have >1 versions of Perl, you have additional headaches, because you need to do the following: perl-5.8 installed? ( depend on foo ) perl-5.10 installed? ( depend on perl ( which now provides foo ) ) Obviously, you cant install 5.10 *and* foo, because 5.10 provides foo, and thus would be a file-name collision ( its not so bad because 'core' and 'modules' go in different folders, but some provide stuff in /usr/bin ), not to mention what transpires if we were to support having *both* 5.8 and 5.10 installed. a 5.8 and 5.10 variant for *every* module we currently have would be *lunacy* And for additional fun, every time a package is dual-lifed or non-dual-lifed, whether it be by upstream, or by locally hacking around it, you thus have to go an adjust every single ebuild that was using that module to handle the change, sometimes while still supporting the previous lifelyness. ( And some will be secretive, because if they just previously depended on perl for that feature , and it is no longer provided by perl itself, then you might have a problem ) Rumours are spreading upstream might be solving the dual life problem somewhat, and hopefully, this will make life easier, and make more up-to-date editions of Perl viable in the tree http://www.modernperlbooks.com/mt/2009/05/what-is-a-stable-core-anyway-the-dual-lived-problem.html
> perl-5.8 installed? ( > depend on foo > ) > perl-5.10 installed? ( > depend on perl ( which now provides foo ) > ) > I know vanishingly little about packages, but isn't that what slotting is supposed to do? The same thing that lets us have qt:3 and qt:4 as sane dependencies?
(In reply to comment #74) > > perl-5.8 installed? ( > > depend on foo > > ) > > perl-5.10 installed? ( > > depend on perl ( which now provides foo ) > > ) > > > > I know vanishingly little about packages, but isn't that what slotting is > supposed to do? The same thing that lets us have qt:3 and qt:4 as sane > dependencies? > no, slotting doesn't solve the need for conditional dependencies. Especially in this case. What you need to have is some way to say "I need foo" without having to specify "where is foo". All slotting permits you to do is have parallel installs of the same package. With slotted Perl, the equation gets harder, because not only do you have to get dependencies right for both scenarios, you need to install it differently, and multiply, once for every version of Perl. Unless of course, you fancy slotting every module in tree, so there's an ebuild per Perl version, and that I do not fancy. PHP4/PHP5 had some alternative to that for a while, with having an entirely separate category, and modules existing dually in 2 categories, but that sort of stuff is sheer sillyness. No sane person will want to maintain that.
> no, slotting doesn't solve the need for conditional dependencies. Especially in > this case. What you need to have is some way to say "I need foo" without having > to specify "where is foo". > > All slotting permits you to do is have parallel installs of the same package. > > With slotted Perl, the equation gets harder, because not only do you have to > get dependencies right for both scenarios, you need to install it differently, > and multiply, once for every version of Perl. > > Unless of course, you fancy slotting every module in tree, so there's an ebuild > per Perl version, and that I do not fancy. PHP4/PHP5 had some alternative to > that for a while, with having an entirely separate category, and modules > existing dually in 2 categories, but that sort of stuff is sheer sillyness. No > sane person will want to maintain that. > What I've seen as the 'proper' way of doing this with the tools we have is to provide a virtual dependency if you fulfill a given interface/command-line requirement. Outside packages could depend on having any version installed, or a specific slotted version. My question is, given that support for 5.8.8 is gone, and that virtually all development and support is on at least 5.10; including the documentation and support I need for utf8/unicode handling; why haven't we been/aren't we testing 5.10 as a stable candidate for our general use and offer 5.8 slotted for those who need it. As a first stab I'd see slotted versions of Perl, with one eselected as the primary version. All the extra Perl things would compile for it. If there's a need for a slotted version of those packages or virtual dependencies that can be addressed later.
i think, we simply need 5.10 in portage
(In reply to comment #76) > > What I've seen as the 'proper' way of doing this with the tools we have is to > provide a virtual dependency if you fulfill a given interface/command-line > requirement. Outside packages could depend on having any version installed, or > a specific slotted version. > See virtual/perl-* But its not as simple as that, because we have several hundered modules which have to be pointed at these virtuals. And if upstream change *again*, ie: add another module to core/remove it from core, we'll have to add virtuals for that, and possibly change everything that depended on that module to the virtual. > My question is, given that support for 5.8.8 is gone, and that virtually all > development and support is on at least 5.10; including the documentation and > support I need for utf8/unicode handling; why haven't we been/aren't we testing > 5.10 as a stable candidate for our general use and offer 5.8 slotted for those > who need it. I believe this is partially due to the dual life issue complications, ie: we have known problems that are yet unsolved, so putting it into stable portage is infeasible, it'll just escalate the support requirements. > As a first stab I'd see slotted versions of Perl, with one eselected as the > primary version. All the extra Perl things would compile for it. If there's a > need for a slotted version of those packages or virtual dependencies that can > be addressed later. Its not that simple, if you have >1 versions of perl, every perl module will have to install a copy for every version of perl, one way or another. Ruby had this for a while and had 1.8 and 1.9 in parallel supported, but it was dropped because it was just too complicated. *FAILING* to do this will result in a /heavily/ broken perl install, and the current task of 'perl-cleaner' ( which remerges everything built vs an old perl so it continues to work ) will become useless.
Added the perl-experimental overlay... only it isn't quite working as desired. perl -MCPAN -e 'autobundle' echo /root/.cpan/Bundle/Snapshot_2009_06_13_00.pm paludis --permit-unsafe-uninstalls -u virtual/perl-IO-Compress-{Base,Bzip2,Zlib} perl-core/IO-Compress-{Base,Bzip2,Zlib} perl-core/Compress-Zlib paludis -i =dev-lang/perl-5.10.0-r2 perl -MCPAN -e 'o conf init connect_to_internet_ok urllist' perl -MCPAN -e 'install Bundle::Snapshot_2009_06_13_00' (Interactive) Running install for module 'Gtk2::Helper' Running make for T/TS/TSCH/Gtk2-1.220.tar.gz Panic: Some prerequisites is not available, please investigate...Can't locate YAML/Syck.pm in @INC (@INC contains: /etc/perl /usr/lib/perl5/vendor_perl/5.10.0/x86_64-linux /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl /usr/lib/perl5/site_perl/5.10.0/x86_64-linux /usr/lib/perl5/site_perl/5.10.0 /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl /usr/lib/perl5/5.10.0/x86_64-linux /usr/lib/perl5/5.10.0 /usr/local/lib/site_perl /etc/paludis/repositories) at /usr/lib/perl5/vendor_perl/5.10.0/CPAN/Distribution.pm line 639. paludis -i YAML-Syck perl -MCPAN -e 'install Bundle::Snapshot_2009_06_13_00' Panic: Some prerequisites is not available, please investigate...--- prereq: - - Pango - b (Unmask/keyword this...) paludis -i dev-perl/Pango perl -MCPAN -e 'install Bundle::Snapshot_2009_06_13_00' Only when I try to run perl-cleaner next I have a problem: perl-cleaner wants to use emerge, and does not seem to have an option for another package-manger like paludis.
(In reply to comment #79) > Added the perl-experimental overlay... only it isn't quite working as desired. > > Only when I try to run perl-cleaner next I have a problem: perl-cleaner wants > to use emerge, and does not seem to have an option for another package-manger > like paludis. I believe you can give it the 'ask' parmeter, and then use that to tell paludis to do it instead, but I cant recall how reliable this is. I basically ran some code over /var/db/pkg/{dev-perl/perl-core} to extract everything that was installed and told paludis to install -1 it. I cant recall whether or not I empty-tree'd just to be sure.
(In reply to comment #80) > (In reply to comment #79) > > Added the perl-experimental overlay... only it isn't quite working as desired. > > > > > Only when I try to run perl-cleaner next I have a problem: perl-cleaner wants > > to use emerge, and does not seem to have an option for another package-manger > > like paludis. > > I believe you can give it the 'ask' parmeter, and then use that to tell paludis > to do it instead, but I cant recall how reliable this is. > > I basically ran some code over /var/db/pkg/{dev-perl/perl-core} to extract > everything that was installed and told paludis to install -1 it. > > I cant recall whether or not I empty-tree'd just to be sure. > No, that doesn't work, if you read the source for /usr/bin/perl-cleaner it uses emerge only, it doesn't even rely on equery results, at least grepping for equery yields nothing, I see lots of emerge lines though. I think replacing just the actual install ones with paludis and running emerge --regen before perl-cleaner-paludis suffices. == I also had another idea. Each version of dev-lang/perl should provide virtual/perl-whatever matches. This would allow anything that's integrated in to core relative to prior versions to be exported out as a virtual dep. Then anything that depended on a perl-module would be instead migrated to virtual/perl-whatever which would be provided by a newer revision of the older packages (it'd only have to be made once). Anything could depend on perl >= given core version as required. The only alternative I can see is to add post-install, pre-remove hooks to cpan and have those modify a per-perl slotting of virtual deps. Then a package could depend on virtual/perl-whatever-vers:versionslot
(In reply to comment #81) > > I also had another idea. Each version of dev-lang/perl should provide > virtual/perl-whatever matches. That would be entirely useless, modules *dont* depend on a given version of perl except in unusual conditions. They only depend on modules, which may-or-may not be provided by perl itself. Artificially adding forced dependencies on given perl versions would be a step backwards. > This would allow anything that's integrated in > to core relative to prior versions to be exported out as a virtual dep. "Relative to prior versions" is a bit vague, modules as far as I've seen have a tendency to attain core status, and then stay like that for the foreseeable future for "legacy" reasons. In order to anticipate this happening in a future Perl, one would need to preemptively provide a virtual for every package, and have *all* Perl dependencies working purely on virtuals, and I can't see that happening any time soon. > Then > anything that depended on a perl-module would be instead migrated to > virtual/perl-whatever which would be provided by a newer revision of the older > packages (it'd only have to be made once). Anything could depend on perl >= > given core version as required. That would ultimately result in hundreds of virtual deps. Maintenance nightmare. > The only alternative I can see is to add post-install, pre-remove hooks to cpan > and have those modify a per-perl slotting of virtual deps. Then a package > could depend on virtual/perl-whatever-vers:versionslot > Eh? I don't really understand what you're trying to say here, but slotted versions of anything module-wise will ultimately end up scaling up the maintenance work required. As it is, perl herd is *understaffed* in proportion to the amount of maintenance work required. Which is one of the reasons 5.10 isn't in tree to start with is because the technical problems with it require more staffing overhead than we presently have. ( nb: some of your arguments made I may have miss-understood, I attempted my best to understand, but there's plausibly some loss, if my arguments here about 5.10 being absent are incorrect, please somebody from herd correct me, but this is the picture I've obtained so far )
'virtual/perl-', 'dev-perl' and 'perl-core': perl -MModule::CoreList -E 'say join "\n", keys %{$Module::CoreList::version{$]}}' Can't this module be called in the .eclass somewhere, get rid of 'virtual/perl-', and just depend on the module and version? IOW, maybe just hack up some bogus ebuild names for modules in 'core' and append them to the cache, so satisfying the package manager's deptree when needed? Then, you can get rid of 'core' too. They are defined above per version of perl and don't really seem to matter anyway... To slot, or not to slot: ls -lh /usr/bin/perl lrwxrwxrwx 1 root root 10 2009-06-02 16:20 /usr/bin/perl -> perl5.10.0 'perl': it's a symlink. Changing that should be all that's needed to "switch versions". What's the problem then to 'SLOT' and eselect. (Anyone using perl should know to do this anyway, so you're just making it generic to portage, or whatever... with 'eselect'.) Calling it directly, not via symlink, hardwires the 'old binary', if needed in a particular script. This is all normal and as old as perl is, from what I know about it... (which isn't all that much, really). So now we have co-existing fully installed versions of perl, and it's not (never was, shouldn't be) a problem. Ebuilds for modules shouldn't care which perl version is installed (since perl doesn't care), unless it's specified in the module that in fact a later version of perl is required that what is called from /usr/bin/perl. Modules will be installed in @INC... and speaking of @INC, modules installed with perl itself are going to be later in @INC, so as it doesn't matter if there are two versions installed... why, really, do we have perl-core vs dev-perl? To illustrate: perl -MModule::CoreList -E 'say $Module::CoreList::version{$]}->{IO::Zlib}' 1.07 That was installed with perl. perl -MIO::Zlib -E 'say $IO::Zlib::VERSION' 1.09 That was installed later, probably as a dependency of something else. locate IO/Zlib.pm /usr/lib/perl5/5.10.0/IO/Zlib.pm <----- 1.07 /usr/lib/perl5/vendor_perl/5.10.0/IO/Zlib.pm <----- 1.09 And so both versions are really still there. But the first isn't touched by perl. So, all is as it should be in perl. COLLISION_IGNORE..??? Maybe put it in the perl.eclass, so created for whatever folders the base install for the perl version called used? Solve a lot of hassles? Your new perl goes in as a slot, eselect changes the symlink when you feel like upgrading everything, and the rest is nonsense that violates DRY in a big way, making this far more burdensome a task than is necessary for perl installs. IMO... given what I know about it. Then really, all we need is a one-to-one correspondence of latest CPAN module distribution tarballs to dev-perl/*.ebuilds, and perhaps a way to resolve the needed MODULE to the needed dependencies (as a helper to the user), then to dump some ebuilds into an overlay and start your package manager... I'm just not sure that anyone is looking at the original decisions about perl modules and the official Gentoo overlay with a truly skeptical perspective enough to say, hey! this doesn't make sense, why do we still do it like this? Rather, understandably, folks are looking at it as a massive burden simply to maintain it (never mind improving it), mostly because of poor original planning, from what I can see... so therefore you wind up making three ebuilds where one should suffice. It is just plainly nonsensical. Yet, we keep doing it... So, who will, rather, who CAN, fix it all up so it's done right, then? There is no perl "herd", just helpful folks making commits on the sly (not being part of the 'herd') and a single largely, though not entirely, non-active (WRT perl) developer. Of these others that help here and there, none is going to risk taking the hits for making big changes, even if it's undeniably the right thing to do, I wager. Also, just to mention it, since it comes up occasionally, the "dual life" problem for package managers really *doesn't apply* to Gentoo. Being a source distro, we don't have issues with *binary compatibility* of SOURCE FILES distributed, right? It just shouldn't matter at all.
any news available?
(In reply to comment #84) > any news available? > Not officially, it seems. I understand there has been a snapshot available for a while that is basically a code freeze on 5.10.1 -- which is coming in a week or so. So I hear. ;-) IDK if the devs have a specific plan to get it into the tree, or not. With this release of perl are many fixes to 5.10.0 -- it surely would make sense to work up an ebuild in the tree for this pending release. Meanwhile, I just made a patch for this: http://rt.perl.org/rt3/Public/Bug/Display.html?id=49472 (the patch here: http://www.nntp.perl.org/group/perl.perl5.changes/2008/02/msg21106.html) since "unknown error" instead of a syntax error on line number: X -- isn't very helpful in developing catalyst apps. ;-) It's a one line change and possibly not important if you don't see the errors with what you're doing on 5.10.0 now... though perhaps it should be fixed up for any new testers of 5.10.0, maybe along with some other important patches, since they are, it seems, available. But... since they're all rolled up in the pending release, maybe the next ebuild in the overlay (gentoo..??) will be available soon and will just be for 5.10.1. ;-)
Created an attachment (id=198731) [details] 925_attributes.patch "unknown error" bug See here, for example: http://www.nabble.com/-MacPorts---19604:-Consider-patching-perl-5.10-td23490367.html
http://archives.gentoo.org/gentoo-dev/msg_4dc14d53f9ce9e2ccaf868deca67b295.xml
Good news: http://github.com/github/perl/blob/d79203520c4254550b36937dae4d767b6a21d93d/pod/perl5101delta.pod Yes, we have release notes :)
Yay, 5.10 RC1 is out. Anyone fancies making an ebuild? ;)
(In reply to comment #13) > (In reply to comment #8) > > -Dlocincpth="/usr/src/linux/include" is something that actually breaks things > > (net-snmp to be specific) > > Not sure why this was added, but I'd like it to be removed if possible. This include path *must* go away. It is insane to include kernel header files in code that runs in user space. There is a very good reason to use header files installed by sys-kernel/linux-headers iso the ones found in /usr/src/linux/include : those files are filled with black magic that will never work if you mix files from /usr/src/linux and /usr/include. e.g. bug 281380 ...
Perl 5.10.1 has been released to CPAN: http://search.cpan.org/~dapm/perl-5.10.1/
FYI, spamassassin fails to emerge with perl 5.10 due to a sandbox violation: F: mkdir S: deny P: /etc/mail A: /etc/mail R: /etc/mail C: /usr/bin/perl5.10.1 -MExtUtils::Command -e mkpath -- /etc/mail/spamassassin F: mkdir S: deny P: /usr/share/spamassassin A: /usr/share/spamassassin R: /usr/share/spamassassin C: /usr/bin/perl5.10.1 -MExtUtils::Command -e mkpath -- /usr/share/spamassassin
Disregard this, was bug #215716 (In reply to comment #92) > FYI, spamassassin fails to emerge with perl 5.10 due to a sandbox violation:
(In reply to comment #91) > Perl 5.10.1 has been released to CPAN: > http://search.cpan.org/~dapm/perl-5.10.1/ > How come the perl-experimental overlay isn't merged with the tree as unstable? It doesn't seem that hard...
Perl 5.10.1 is in portage! Finally! Thank you, Torsten. http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-lang/perl/perl-5.10.1.ebuild
(In reply to comment #95) > Perl 5.10.1 is in portage! Finally! Thank you, Torsten. > > http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-lang/perl/perl-5.10.1.ebuild > It's not finally... :-( Ebuilds in portage without KEYWORDS. Now overlay is true
Next stop is perl-5.10.1. Please file bugs that block bug 280724 for any issue. Thanks for your patience. BTW: The perl team is looking for skilled developers
(In reply to comment #97) > Next stop is perl-5.10.1. > Please file bugs that block bug 280724 for any issue. > > Thanks for your patience. > > > BTW: The perl team is looking for skilled developers > I get this = Calculating dependencies - * Digest verification failed: * /usr/portage/dev-lang/perl/perl-5.10.1.ebuild * Reason: Failed on RMD160 verification * Got: a09064942c9cae21e52dd1240ff542552b3aa1a5 * Expected: 7fc3a713ff5b490dfd98d71d8402f57495c6dec3
(In reply to comment #98) > I get this = > > Calculating dependencies - * Digest verification failed: Thanks. Fixed.
