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? 14 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.
        • Some distributions already split out some core modules into different packages; like, for example, CGI.pm. 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 :)
            • Ah, compliance. That means also a test suite that can be run against an isntalled perl, and that's something that's standing in the TODO list for some time too.
              • No it doesn't.

                I'm talking about a compliant setup for the binary packages, not for the Perl distribution itself.
        • We must install dual-life modules in CORE in order for them to be loaded. Otherwise, if we install these modules in SITE, the old version in CORE will shadow the new version. That's what the UNINST ExtUtils::MakeMaker parameter is for (--uninstall for Module::Build). See for example CPAN-RT#22130 [cpan.org].
          --
          Close the world. txEn eht nepO

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

      • This is done on the recent Fedora packages. The @INC goes /usr/lib/perl5/site_perl, /usr/lib/perl5/vendor_perl, /usr/lib/perl5/5.8.8. The vendor_perl is there for the RPM packaged modules to keep them separate from locally installed ones. And it is deliberately before the core one so it is possible to install updated versions of core modules.
      • This issue is in some ways broader than just whether or not a module has a dual-life. For example, any module for which a critical upgrade is needed can present the same problem. For some reason or another, you may find yourself wanting to replace one module without replacing the entire package.

        One obvious thing to consider is to have an "override" directory added to @INC. For further discussion of that option, please see the section: =head2 Why isn't there a directory to override Perl's library?

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