Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

148 newly installed, Do you want to continue [Y/n]? 9 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • ... but fails horribly for me when simply trying to deploy an application. To explain this I'll focus on my prefered distribution, debian. Installing debian packages is simply, you get it from the standard repositories, or 3rdparty ones which laos relate to the current set of distributions (stable/testing/unstable). All dependencies *including* the C based APIs that might be required are resolved and simply installed (without asking a million questions, yes I know you can turn it off, but it's hard to find
    --
    Hmmm... someone stole my signature...

    • Tests are certainly necessary to run on every system for which the configuration is not a priori known.

      OS vendor package repositories circumvent this by saying “any package in this set of packages is known with a certain degree of confidence to play well well with any other package within the same set”. This is what release engineering is about: working out which set of packages works together stably.

      The CPAN has no provisions for any stable set of particular distributions. Instead, anything tha

      • The CP5.6.2AN is a brilliant idea that could provide a lot of feedback to CPAN uploaders as well as CPAN users. I could imagine a useful subscription service that bundled together dependencies which tested successfully on a given platform.

        • What I really like about Debian testing is that it's already here. :-) It has plenty of maintainers that are already watching over about the modules. There is already bug-tracing tool for the packaged versions. Also another nice thing about packaging is that it is easy to include patches to the original source. For example Perl 5.10.0 it self has 22 packaging releases and includes 58 fixes patches (you can see which http://patch-tracking.debian.net/package/perl/5.10.0-22 [debian.net] search for "fixes/"). For a private

          • Thing is, with good-quality test suites (which Debian mostly lacks), you can automate much of the release engineering process. That’s part of a possible extrapolation from David’s post: a system whereby a new release automatically becomes part of the testing package set if it passes not only its own test suite against when running against the rest of testing, but with it installed, all of its (immediate and indirect) dependents within testing also pass theirs. That way you could get a “rol

      • The tests are important, everyone knows. One think that I want to try is to package Perl modules and keep the tests. Let's say in "/usr/share/t/package-name". Then it will be possible to run tests again when ever there will be a need. And this "need" should come up every time there is a new versions of a module as every other module that depends on the new one should be retested. At the end of the chain it includes our own "product" tests. This can not be done with CPAN shell, can it? Imagine that you start
  • I'm interested in your reasoning for running "Perl without threads". I've done a lot of work with developing and deploying Perl and mod_perl apps on Debian and have yet to find a reason to build my own perl executable. Does building a Perl without threading support have some advantage over the core build?
    • Actually it was a "company decision". The Perl without threads is used here for a long time. The main reason is, that in some cases Perl without threads is 10-30% faster and as we never use threads here, it's fine to disable them. Actually I would like to know who and how uses Perl threads as one can never be sure if some CPAN code is (or stays) thread safe. And probably using POE [cpan.org], AnyEvent [cpan.org] or other event loop system is much better than threads.

      • Perl threads aren’t really threads, they’re a hobbled emulation of fork() that still doesn’t work right in many cases (taint mode, anyone?). There are only two reasons to use Perl threads: 1) Windows 2) mod_perl. Both are bad ideas as far as I’m concerned. I prefer to compile Perl without threads and use fork() when I need fork().

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.