use Perl

• Apply this patch to enable dh-make-perl to retrieve module name and version information from META.yml.
• After running dh-make-perl tweak file debian/rules. Replace

  $(PERL) Makefile.PL INSTALLDIRS=vendor
  $(MAKE) OPTIMIZE="$(OPTIMIZE)" LD_RUN_PATH=""

  with

  $(PERL) Build.PL installdirs=vendor
  OPTIMIZE="$(OPTIMIZE)" LD_RUN_PATH="" ./Build

  and

  $(MAKE) install PREFIX=$(TMP)/usr

  with

  ./Build install destdir=$(TMP)

I'd add native Module::Build support to dh-make-perl but this code badly needs refactoring before adding more code.

On similar note why SourceForge disallow SSH access to their CVS servers when they allow you to modify files in CVSROOT? If I can add commit and loginfo scripts there I can run arbitrary code on the server too.

For sysamins: better not waste your time on false security measures especially when it makes life of legimate users harder.

$ perl5.6.1 Makefile.PL
[Thu Aug  7 15:09:35 2003] Makefile.PL: Warning: prerequisite Email::Valid failed to load: Can't locate Email/Valid.pm in @INC (@INC contains: /home/perl-5.6.1/lib/5.6.1/i686-linux /home/perl-5.6.1/lib/5.6.1 /home/perl-5.6.1/lib/site_perl/5.6.1/i686-linux /home/perl-5.6.1/lib/site_perl/5.6.1 /home/perl-5.6.1/lib/site_perl .) at (eval 5) line 3.
[Thu Aug  7 15:09:35 2003] Makefile.PL: Warning: prerequisite MIME::Lite failed to load: Can't locate MIME/Lite.pm in @INC (@INC contains: /home/perl-5.6.1/lib/5.6.1/i686-linux /home/perl-5.6.1/lib/5.6.1 /home/perl-5.6.1/lib/site_perl/5.6.1/i686-linux /home/perl-5.6.1/lib/site_perl/5.6.1 /home/perl-5.6.1/lib/site_perl .) at (eval 6) line 3.
Writing Makefile for FillForm

Turned out it is because CGI::Carp was listed in PREREQ_PM section.

Seeing a recent patch at bug report #23141 makes me wonder if doing local $_; while() { ... } will stop working too in general case. In other words if I get things correctly with this patch no CPAN module can use $_ even if it is localized because $_ may be readonly or have some magic attached to it and local will not remove it. Looks like using local with global variables is almost always bad idea unless callee can allow certain assuptions about callers (what is seldom a case for, say, CPAN modules).

The URL

    http://martynov.org/tgz/Data-Dumper-2.12_02.tar.gz

has entered CPAN as

  file: $CPAN/authors/id/I/IL/ILYAM/Data-Dumper-2.12_02.tar.gz
  size: 37466 bytes
   md5: 5bf08437a88003604a95cc08418d6b57

This release fixes build errors on 5.6.x with ithreads. Thanks to crazyinsomniac for the bug report. Hopefully there will be no other bug reports and I'll be able to rerelease 2.12_02 as a stable version 2.121.

I can understand why somebody may want to use Perl as a templating language - if you are in this camp you may like HTML::Mason (I used to like it but I switched to TT2 now). But using HTML::Mason as a framework to maintain Perl code for anything other than templating tasks is just nonsence. I just don't undestand why. Code in Mason components is harder to unit test than Perl modules, it takes more effort to structure your code - in ordinary Perl you have packages and subroutines, in Mason you can emulate something like this with components and subcomponents but it takes more effort and finally Mason has quite confusing OOP model which may be ok for templates but is not really up to task for anything complex. How can it be easier to put your Perl code in Mason components instead of Perl modules?

With perl it's core is much smaller and many core libs have standalone versions avialable from CPAN which still work with old perls. Basically I can keep in my head list of all things I should I avoid if I want to be backward compatible even back to 5.00503. Try this with PHP.