Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 206455 - dev-lang/perl-5.10.0 is out
Summary: dev-lang/perl-5.10.0 is out
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All All
: High enhancement with 7 votes (vote)
Assignee: Gentoo Perl team
URL: http://www.perl.org
Whiteboard:
Keywords:
: 219477 (view as bug list)
Depends on: 237378
Blocks: 179110 247315 perl-5.10.1
  Show dependency tree
 
Reported: 2008-01-17 19:39 UTC by Moshe Kamensky
Modified: 2009-09-30 10:27 UTC (History)
39 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
ebuilds and patches for perl and libperl 5.10.0 (perl-5.10.tar.bz2,17.09 KB, application/octet-stream)
2008-01-17 19:45 UTC, Moshe Kamensky
Details
New Perl 5.10.0 lib64 patch (perl-5.10.0-lib64.patch,3.29 KB, patch)
2008-01-25 18:45 UTC, Bor
Details | Diff
Removes the gcc-4.2 patch that doesn't exist. (missingpatch.patch,1.74 KB, patch)
2008-12-29 20:45 UTC, Jason Switzer
Details | Diff
build.log (build.log,31.23 KB, text/plain)
2009-01-02 10:39 UTC, Caleb Cushing
Details
925_attributes.patch "unknown error" bug (925_attributes.patch,334 bytes, patch)
2009-07-21 19:27 UTC, michael higgins
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Moshe Kamensky 2008-01-17 19:39:17 UTC
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
Comment 1 Moshe Kamensky 2008-01-17 19:45:00 UTC
Created attachment 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
Comment 2 Michele Beltrame 2008-01-21 23:58:16 UTC
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...

Comment 3 Bor 2008-01-25 18:45:10 UTC
Created attachment 141778 [details, diff]
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?
Comment 4 Andreas Proteus 2008-02-24 22:52:13 UTC
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.
Comment 5 Hinrik Örn Sigurðsson 2008-04-17 09:07:18 UTC
dev-perl/Module-CoreList is also included in 5.10 now.
Comment 6 Yuval Yaari (RETIRED) gentoo-dev 2008-04-23 21:59:36 UTC
In the perl-experimental overlay!
Sorry for keeping you waiting.
Please report problems/whatever...
Comment 7 Torsten Veller (RETIRED) gentoo-dev 2008-04-27 15:35:44 UTC
*** Bug 219477 has been marked as a duplicate of this bug. ***
Comment 8 Rafał Mużyło 2008-05-10 07:18:39 UTC
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.
Comment 9 Michele Beltrame 2008-05-30 08:44:05 UTC
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.
Comment 10 Sergiy Borodych 2008-06-03 07:31:38 UTC
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
Comment 11 Scott Thomson 2008-06-03 14:59:35 UTC
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.
Comment 12 Sergiy Borodych 2008-06-04 12:09:45 UTC
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
Comment 13 Fabian Groffen gentoo-dev 2008-06-15 14:38:04 UTC
(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
Comment 14 Fabian Groffen gentoo-dev 2008-06-22 09:31:29 UTC
@perl-team: what can I do to help?  I have it all working, patches ported, etc. in the prefix overlay.
Comment 15 Robert Buchholz (RETIRED) gentoo-dev 2008-06-24 01:48:19 UTC
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.
Comment 16 Fabian Groffen gentoo-dev 2008-06-24 11:56:58 UTC
rbu, thanks.  For grabs: http://overlays.gentoo.org/proj/alt/changeset/26266
Comment 17 Peter Volkov (RETIRED) gentoo-dev 2008-07-12 19:29:26 UTC
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.
Comment 18 Denis Kaganovich 2008-09-09 16:40:10 UTC
Also IMHO better to rename "perl-5.10.0*" to "perl-5.100*"
Comment 19 Jason Switzer 2008-09-11 22:58:41 UTC
(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.
Comment 20 Najib Idrissi 2008-11-04 08:20:28 UTC
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?
Comment 21 Pacho Ramos gentoo-dev 2008-11-04 17:58:53 UTC
(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

:-)
Comment 22 Najib Idrissi 2008-11-05 09:35:41 UTC
(In reply to comment #21)
Oh, sorry, I was too hurry :D . I didn't check the recent changes. Thanks.
Comment 23 Weedy 2008-11-14 15:40:47 UTC
yet it's still not even hard masked....
Comment 24 Alexandre Rostovtsev (RETIRED) gentoo-dev 2008-11-14 17:42:05 UTC
By the way, perl-5.8 is being end-of-lifed.

http://aspn.activestate.com/ASPN/Mail/Message/perl5-porters/3675589
Comment 25 Jason Switzer 2008-11-16 03:31:07 UTC
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?
Comment 26 Najib Idrissi 2008-12-16 16:26:59 UTC
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!
Comment 27 michael higgins 2008-12-16 21:39:00 UTC
> 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. :(
Comment 28 michael higgins 2008-12-16 21:50:12 UTC
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????
Comment 29 Moshe Kamensky 2008-12-17 00:19:47 UTC
(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)

Comment 30 michael higgins 2008-12-17 08:29:00 UTC
> 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.
Comment 31 michael higgins 2008-12-17 08:46:59 UTC
(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? '-)
Comment 32 Jason Switzer 2008-12-17 13:30:32 UTC
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.
Comment 33 Jason Switzer 2008-12-17 13:48:40 UTC
> 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."
Comment 34 Denis Kaganovich 2008-12-26 10:24:52 UTC
(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.
Comment 35 michael higgins 2008-12-26 19:01:59 UTC
> 
> 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?). 
Comment 36 Caleb Cushing 2008-12-27 23:27:18 UTC
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    
Comment 37 Fabian Groffen gentoo-dev 2008-12-28 10:27:08 UTC
perl-5.10.0 doesn't work well with the Gentoo tree (yet), so you're better off not using it.
Comment 38 James Shaw (Simba7) 2008-12-29 15:01:48 UTC
(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.
Comment 39 Vytautas 2008-12-29 16:24:25 UTC
There will not be 2009.0 at all read Gentoo.org new for more info.
Comment 40 Jason Switzer 2008-12-29 16:36:23 UTC
(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.
Comment 41 Alois Hammer 2008-12-29 16:45:34 UTC
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?
Comment 42 Fabian Groffen gentoo-dev 2008-12-29 16:46:05 UTC
(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.
Comment 43 Jason Switzer 2008-12-29 16:57:02 UTC
(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).
Comment 44 Vytautas 2008-12-29 17:05:04 UTC
 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? 
Comment 45 Andreas Proteus 2008-12-29 17:23:07 UTC
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.
Comment 46 Jason Switzer 2008-12-29 17:29:37 UTC
(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.
Comment 47 Caleb Cushing 2008-12-29 17:41:26 UTC
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.
Comment 48 Jason Switzer 2008-12-29 20:40:45 UTC
(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?
Comment 49 Jason Switzer 2008-12-29 20:44:31 UTC
(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.
Comment 50 Jason Switzer 2008-12-29 20:45:27 UTC
Created attachment 176799 [details, diff]
Removes the gcc-4.2 patch that doesn't exist.

Seems to build on ~amd64 without the patch.
Comment 51 Jason Switzer 2008-12-29 21:11:18 UTC
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
Comment 52 Jason Switzer 2008-12-29 21:23:09 UTC
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.
Comment 53 Caleb Cushing 2008-12-29 21:44:32 UTC
(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 54 mark meissonnier 2008-12-30 07:15:28 UTC
(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?
Comment 55 Jason Switzer 2008-12-30 17:04:36 UTC
> 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
Comment 56 Jason Switzer 2008-12-31 19:10:14 UTC
(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.
Comment 57 Jason Switzer 2008-12-31 21:54:53 UTC
(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.
Comment 58 Caleb Cushing 2009-01-02 10:39:58 UTC
Created attachment 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.
Comment 59 Jason Switzer 2009-01-03 23:11:24 UTC
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.
Comment 60 Caleb Cushing 2009-01-05 17:44:03 UTC
virtual/perl-MIME-Base64 depends on perl 5.8 ...
Comment 61 Caleb Cushing 2009-01-05 19:16:46 UTC
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
Comment 62 Jason Switzer 2009-01-06 00:41:21 UTC
(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.
Comment 63 Caleb Cushing 2009-01-06 10:59:20 UTC
check out bug  #253904 for more info on perl-MIME-Base64
Comment 64 Najib Idrissi 2009-04-30 09:10:41 UTC
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?
Comment 65 Dennis Schridde 2009-04-30 10:24:40 UTC
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.
Comment 66 Najib Idrissi 2009-04-30 12:33:24 UTC
(In reply to comment #65)

That's what I did, and I found no bugs. I didn't test them deeply, though.
Comment 67 Scott Thomson 2009-04-30 13:16:34 UTC
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?
Comment 68 Caleb Cushing 2009-04-30 13:35:52 UTC
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.
Comment 69 Henrique Dias 2009-05-29 10:16:29 UTC
what is necessary to put the perl-5.10 in portage tree?
Comment 70 Kerin Millar 2009-05-29 12:41:47 UTC
> 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.
Comment 71 michael higgins 2009-06-03 18:31:35 UTC
(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?
Comment 72 Oschtan 2009-06-10 09:04:53 UTC
Hm. In portage? In a year+ after adding...
Comment 73 Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2009-06-10 19:36:34 UTC
(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



Comment 74 Michael Evans 2009-06-13 07:16:17 UTC
>   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?
Comment 75 Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2009-06-13 07:49:21 UTC
(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.
Comment 76 Michael Evans 2009-06-13 17:44:17 UTC
> 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.
Comment 77 Opportunist 2009-06-13 18:33:42 UTC
i think, we simply need 5.10 in portage 
Comment 78 Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2009-06-13 23:46:24 UTC
(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. 
Comment 79 Michael Evans 2009-06-14 05:36:27 UTC
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.
Comment 80 Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2009-06-14 06:20:43 UTC
(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.
Comment 81 Michael Evans 2009-06-14 07:37:03 UTC
(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
Comment 82 Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2009-06-14 08:37:59 UTC
(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 ) 
Comment 83 michael higgins 2009-06-15 17:48:54 UTC
'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.
Comment 84 Opportunist 2009-07-18 17:03:14 UTC
any news available?
Comment 85 michael higgins 2009-07-21 19:15:08 UTC
(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. ;-)
Comment 86 michael higgins 2009-07-21 19:27:19 UTC
Created attachment 198731 [details, diff]
925_attributes.patch "unknown error" bug

See here, for example: 
http://www.nabble.com/-MacPorts---19604:-Consider-patching-perl-5.10-td23490367.html
Comment 87 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2009-08-02 13:17:24 UTC
http://archives.gentoo.org/gentoo-dev/msg_4dc14d53f9ce9e2ccaf868deca67b295.xml
Comment 88 Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2009-08-06 16:35:58 UTC
Good news: http://github.com/github/perl/blob/d79203520c4254550b36937dae4d767b6a21d93d/pod/perl5101delta.pod

Yes, we have release notes :)
Comment 89 Michele Beltrame 2009-08-07 23:38:33 UTC
Yay, 5.10 RC1 is out. Anyone fancies making an ebuild? ;)
Comment 90 Alin Năstac (RETIRED) gentoo-dev 2009-08-22 13:39:04 UTC
(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 ...
Comment 91 Najib Idrissi 2009-08-24 07:35:14 UTC
Perl 5.10.1 has been released to CPAN: http://search.cpan.org/~dapm/perl-5.10.1/
Comment 92 Nathan March 2009-08-26 22:27:05 UTC
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 
Comment 93 Nathan March 2009-08-26 23:30:18 UTC
Disregard this, was bug #215716

(In reply to comment #92)
> FYI, spamassassin fails to emerge with perl 5.10 due to a sandbox violation:
Comment 94 Kaleb Elwert (belak) 2009-09-02 13:37:08 UTC
(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...
Comment 95 Alexandre Rostovtsev (RETIRED) gentoo-dev 2009-09-27 17:14:25 UTC
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
Comment 96 Oschtan 2009-09-28 05:36:00 UTC
(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
Comment 97 Torsten Veller (RETIRED) gentoo-dev 2009-09-28 18:12:48 UTC
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
Comment 98 Marko Weber Bürgermeister 2009-09-29 21:23:03 UTC
(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

Comment 99 Torsten Veller (RETIRED) gentoo-dev 2009-09-29 21:40:51 UTC
(In reply to comment #98)
> I get this =
> 
> Calculating dependencies - * Digest verification failed:

Thanks. Fixed.