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.

Are we framing"dual-life" modules the wrong way? 4 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
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.

        • 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.

          A distribution-supplied update to a core module should go into ‘vendor’. That leaves ‘site’ (probably under /usr/local/) free for the local sys-admin, who may wish to manually install newer versions of modules than those supplied in the vendor's packages.

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