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? 25 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?

    • A net result would be that even more people would be less willing to use some modules. All too often, we encounter the restriction that a solution may not contain any non-core modules...

      • There are already many vendors who slice and dice the Perl package. There’s no real guarantee that a module will be there even if it’s “in core” anyway. We would just be blessing the de-facto situation. Hopefully an insistence on code modules only would then become untenable for enough people that maybe someone would finally find motivation for a good module bundling solution.

        As for the places which would still insist that only core modules be used, well, I don’t think we can

        • Awesome! I'm stupid for trying to make life easy for the rsnapshot users!

          • You are making no sense whatsoever.

            • You said:

              As for the places which would still insist that only core modules be used, well, I don’t think we can protect stupid people from themselves

              Rsnapshot doesn't require any non-core modules, and so has had to reinvent various wheels. Which, I guess, makes me, the current maintainer, stupid.

              What doesn't make sense is removing stuff from the perl 5 core distribution. Although I live in hope that perl 6 will be slim and sylph-like, with only those modules included which are required to easily

              • When I say “stupid”, I mean workplaces that could easily install modules but refuse. Writing what’s effectively shrink-wrap software in Perl (ie. rsnapshot has to run on any number of machines, none of which you have any control over) is a very different situation.

                However, even in your case, I don’t know that trimming down the core would be a problem. Are you better served working against a) a large but insufficient core, reinventing various wheels as needed, or b) a minimal core a

  • Debian GNU/Linux ... ha[s] a recurring problem with "dual-life" modules. ... The primary problem seems to be that binary packaging systems consider files to be inviolate.

    In Debian's case it's (largely) true that one file path belongs to one package, but that isn't actually a problem for dual-life Perl modules. Core modules (such as CGI, which come in the perl-base and perl-modules packages) and Cpan modules (such as YAML, which each come in their own packages, such as libyaml-perl) are installed to di

  • One answer might be to encourage distributors to split dual-life modules right out, not include them in the perl package at all, and then have e.g. perl-5.8.8 depends on Scalar-List-Utils-1.18. This doesn't work for systems which build from source, of course, as installing the module from CPAN requires a working perl...
    • People that install from source aren't the problem here.
    • Beard. When I was the Gentoo perl guy, we had PDEPEND's added precisely for this scenario - so that we could build newer versions of core modules immediately following the build/install of perl itself.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.