Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: bmarkus on September 19, 2011, 02:07:01 PM
-
Current Perl 5.10.1 extension is two years old; upstream is 5.14.1 I have no problem with it, but maybe its the time to update at least in 4.x repo
-
I'd like to strongly second this request.
Now, I've done a bit of counting and found ca. 38 'perl_*.tcz' extensions in the 3.x repository: 23 submitted by user AlabamaPaul, 5 by BashlykovNikolay (which I could not find any more in the members list), 4 each by juanito and Arslan S., and 2 by bmarkus.
Unlike the situation with Python there are only a few extensions in the 3.x repository that depend on a Perl module and are themselves not a Perl module extension (e.g. 'autoconf.tcz', 'frozen-bubble.tcz', 'icon-naming-utils.tcz', 'intltool.tcz', 'pcb.tcz' and 'system-tools-backends.tcz'). Their dependencies are 'perl_xml_parser.tcz', 'perl_xml_simple.tcz', 'perl_gettext.tcz', and 'perl_Net_DBus.tcz'.
In my own professional experience (gained predominantly a few years ago) a Perl script created for example during then 5.6 phase would typically not need any change to run on a 5.8 or 5.10 system. I like to think that much more effort has been put into staying backward compatible for the Perl5 version progression. Therefore I'd be highly surprised if any problems would arise from the ca. 37 extensions that require the 'perl5.tcz' extension (and are themselves not a Perl module).
Considering also that only very few extension contributors would need to coordinate any change I'd like to think that a "big bang" approach (i.e. update 'perl5.tcz' to v5.14.2 and approach the Perl module extensions maybe by prioritising those mentioned above) is quite feasible. Clearly I'm not suggesting to go down a renaming and dual version exercise (along the lines of Python 2.6 vs. 2.7). I think the lower "popularity" that Perl enjoys nowadays and the more contained number of modules should make it easier to take the plunge now still at the very beginning of the 4.x phase. I don't think that the IMHO remote risk of noticeable breakage does warrant a postponement to the TC 5.x phase.
-
Since some, if not all, of the perl modules put files in /usr/local/lib/perl5/site_perl/5.10.1, I'm presuming they'd all have to be modified or rebuilt?
-
I am not very familiar with Perl, but I get the impression that perl modules must be built again with a perl update, ie 5.10 to 5.14. My vote is that we could time the perl upgrade with each major TC version upgrade.
-
I agree that the Perl modules will require a rebuild. It tends to be actually pretty easy, along the lines of:
perl Makefile.PL && make && make test && make install
So, Jason does your vote mean that we now have to wait because we've "missed the boat", or is this more an encouragement to "get cracking"?
-
With the ease of rebuilding Perl modules, and if it does not affect the base system or toolchain, then perhaps now is as good of time as any to update if there is no other reason not to. That is my thoughts, but the decision will rest with Juanito, he would know more about it's potential effects on the base or toolchain.
-
A gtk2-perl extension would be good also.
-
The thought at the moment is to upload a new version of perl5 (5.14.1) and remove all of the perl module extensions until such time as their maintainers rebuild and resubmit them.
Any comments?
-
I'm ready to rebuild my module ASAP
-
new perl5 uploaded and old perl module extensions removed - now's the time to submit new perl module extensions..