Slash Boxes
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.
More | Login | Reply
Loading... please wait.
  • I think (part of) the solution is something that came up in the hallways of YAPC::EU a couple of times: de-core most of the modules and dual-life everything that can feasibly be.

    Now it just needs to happen…

    • I think another solution would be having the perl modules installed using packaging tools on a different path. Like, adding another directory to Perl's @INC and let that be the place where dual-life modules live.
      Igor Sutton
      • The current split is not necessarily a bad one.

        What I just don't understand is why we have dual-life modules install to CORE rather than site, if the module is being upgraded beyond the "core" version that comes with Perl.
        • Some distributions already split out some core modules into different packages; like, for example, There's only one source package, but binary packages can be upgraded independently. I intend to write a README for packagers for perl 5.10.0 in which I'll put that kind of advice. Of course, patches are welcome.
          • Any patches from me would probably just be along the lines of changing "recommended" to "expected" or "required for TPF certification" :)

            Of course, then I'd have to create some form of certification and that would mean joining the TPF and that's a whole other ball game.

            Perhaps "compliant"?

            That way I can file a bug via RedHat Enterprise Support saying "The Perl packaging for blah is non-compliant" :)

            Just make sure the docs have some for of "No Really, Do It This Way" to them :)