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.
 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 the cause of why it fails then... and it fails mostly due to some simple module failing a single test) CPANs problem is mostly due to the tests running for the installation of every package, tests the probably have run already for hundreds or thousand others in a more or less similar environment (at least for those using one of the big standard linux distributions). No real need to rerun this tests on every installation. It's fine for a devel box, because I wont to know that the module I upgrade/install works here, but not when I release and deploy my application. So it would problably make sense to have a BIPAN (a binary installation perl archive network) to simply install the modules, but then again, would this not just duplicate efforts what the actual distributions do. Yes it would, so it's wasted resources, as we probably would never be able to accomodate all the required 3rdparty packages into BIPAN. So it would probably make more sense to have a simple way to generate packages for distributions. Something that extracts the CPAN info and generates the debian packaging dir or it, or the RPM specfile, hence allowing the package maintainers to easy their work. On debian there is already the great cpan2deb (dh-make-perl) which does that from the other side. Maybe some Module::Install could help here, at least for the most common distruibutions (another topic to discuss endlessly) Puh, lengthy comment, sorry bout' that, but thanks for reading through. I'm quite used to the debian distribution, so packaging .deb archives
    --
    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