OK, I think I’ve spent too much time alone with this, so although this is by no means in a “ready for mass distribution testing” stage, I thought I’d open the ebuilds I’ve been working on to testing. You can look at them here and grab the tarball here – but before you do, a ton of explanations, caveats, and general errata:
: DISCLAIMER :
These aren’t necessarily the way gentoo perl is going to go – this is an experiment in slotting and tweaking of the current perl build structure. These will not go into the tree until first, the perl herd agrees, and second, there is a consensus among the community that it is viable. My notes to anyone that wants to give them a whirl:
: Libperl and old perl installs :
Because of slotting, these ebuilds block the old ebuilds for both libperl and perl. In addition, these perl ebuilds have no dep on libperl – this isn’t a mistake 🙂 Rather, after giving this some consideration, it struck me that I am aware of no usage for the libperl static library. So…the perl ebuild builds the libperl(so) and links against it rather than the old static binary. Hopefully this won’t cause too much anguish (we can always go back to a split ebuild if it looks like its needed). I will say the linked perl seems to execute a bit faster and is definitely lighter. The downside of all of this is that you need to unmerge perl and libperl first (so, really, only play with these ebuilds if you don’t mind risking your box – you won’t be risking it, but that’s the mindset I want you to have) since they were all slot 1, and these ebuilds introduce SLOT=$PERL_VERSION.
: perl-cleaner :
Actually, nothing’s been updated in perl-cleaner (though I have some thoughts as a result of this experiment), but I did want to say that all things considered, you shouldn’t need to run it if you try these perl ebuilds. When you unmerge your old perl’s, anything you installed will still be sitting around (since the ebuild clean phase won’t touch anything that wasn’t added by dev-lang/perl), your modules via ebuild should still be available…should be…also, I haven’t tested perl-cleaner after switching to the SLOTted perls, so I make no guarantees on cross compatibility (just to be safe 🙂
: perl-config still needs to be written :
This is significant to know. The new ebuilds for perl in experimental, since they are SLOTted, don’t install on top of each other, but in parallel. But since perl-config is yet to be written, while you can use the multiple versions of perl, you don’t have a quick and clean means of swapping out which is the active profile. These ebuilds do generate $ROOT/etc/env.d/perl files – just need to write the tool still is all.
: perl and ithreads :
Which brings us to a threaded perl install. Time was when you chose one way or the other. With these ebuilds, you instead choose either a non-threaded perl, or both. NOTE: If you have ithreads, the ‘active’ perl is the non-threaded perl, but both are present and available. (see note above about needing a perl-config to be written).
: patches :
Not all of the old patches are incorporated yet. In addition, I’ve redone the sprintf patch to reflect what went into blead perl, and I’ve rewritten the reverse-INC patch to force VENDOR at the top of the stack at all times.
: .ph files :
Not being generated yet. Haven’t had a chance to tackle this. In the version of the perl ebuilds in portage currently, the tactic is to remove all previous .ph files and regenerate these. Obviously this won’t work if you have multiple perl’s now, and it shouldn’t be a big task to fix up, but it isn’t available yet.
: PDPENDs :
OK, this is likely to cause some grumbling, but I’ve added PDEPENDs to a few perl-core modules. The rationale for this is twofold actually. First, in order to avoid collision-protects between /usr/bin/* files installed by dev-lang/perl and a few of our perl-core ebuilds, I needed to remove them prior to merging into the tree. So to be sure you had those files back, I added the packages in question as PDEPENDs. Secondly, if we have a perl-core ebuild (which means the module in question is maintained outside of the perl release cycle), that means that the ebuild is most likely newer than what came with the install of perl your using. And I want nothing more than to make sure you have the latest greatest possible 🙂
: minimal and build flags :
Don’t. These ebuilds may still contain some of the code for these flags, but they haven’t been tested/reworked for the new layout yet. Hey, I said these were experimental! The goal will be to set those PDEPENDs to be ignored if either flag is set, and to rework the extraction sections so that the list of modules, binaries, etc., are contained in a common, external file in FILESDIR – just haven’t gotten that far yet.
: Bug me, not bugzilla :
As these aren’t “sanctioned” ebuilds, please do not file bugs on bugzilla. Now most of my audience knows I just suck at replying to email, but for now I’d like (assuming anyone looks at these) you to send feedback, fixes, patches, etc. to me directly.
: Updates :
Finally, I will do my darndest to keep the dev space as up to date as what I have installed locally, but I don’t want to mislead anyone into thinking this is a live snapshot of my home overlay. This is still a work in progress, and just as liable to go into portage as to be dropped completely (sad but true).
I suppose it goes without say, of course, that you need to be familiar with working with gentoo overlays to even try these, don’t put these on boxes you care about, yada yada yada, if it breaks your system that’s what you get for trusting a sleep deprived dev, so forth and so on.
OK, now off with you. Tell me what you think.