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]? 6 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 that gets uploaded is immediately “released”, so the state of how well everything plays together is constantly in flux. You cannot sanely do without running the test suite under such circumstances.

      The real answer is David Golden’s [dagolden.com].

      • 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
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.