http://www.perlmonks.org?node_id=1186237


in reply to [PPM (Perl Package Manager)] Installing multiple modules from a single ppd file

Hi,

Not sure exactly why a regular ppd isn't up to task, but have you seen

make_ppm_bundle - make a bundle of ppm packages ?

It sounds promising

  • Comment on Re: [PPM (Perl Package Manager)] Installing multiple modules from a single ppd file

Replies are listed 'Best First'.
Re^2: [PPM (Perl Package Manager)] Installing multiple modules from a single ppd file
by syphilis (Archbishop) on Mar 28, 2017 at 11:58 UTC
    It sounds promising

    Yeah ... except that I don't really want to install multiple modules ;-)
    What I'm wanting to do, for Gtk2::WebKit is, firstly, to install the perl-version-specific binary:
    <CODEBASE HREF="http://www.sisyphusion.tk/ppm/x86/Gtk2-WebKit-512.tar. +gz" />
    But then I also want to install the (32-bit) dlls upon which that module depends - something like:
    <CODEBASE HREF="http://www.sisyphusion.tk/ppm/x86/Gtk2-WebKit-dlls.tar +.gz" />
    where the latter command downloads and unpacks a blib that has nothing other than various 32-bit win32 dlls in blib/script - and promptly installs those dlls into $Config{sitebin}.

    That latter command will be the same for all 32-bit win32 perl versions.

    Admittedly, I could just include the contents of that second blib in with the first blib, but then every 32-bit package that I upload to my repo will have the same 24MB of gzipped dlls.
    For me, it's the difference between having to upload 24 x 25MB of tarballs, and having to upload 24 x 1MB of tarballs plus 2 x 24MB tarballs (one for each of 32-bit and 64-bit dlls).
    And bear in mind that I live in rural Australia where third world class (probably even worse) internet connections are the rule.

    Thanks for the reply - and I probably should check your link in case there is something useful there.

    I can achieve what I want using a post-install script. I'd prefer not to do it that way (as it's a bit of a kludge in comparison to "CODEBASE HREF") but I'll do it that way if I have to.

    Cheers,
    Rob

      Hi

      Why not a simple dependency on Alien-Sisyphusion-Gtk2WebKitdlls?

      Something like  <DEPENDENCY NAME="Alien-Sisyphusion-Gtk2WebKitdlls" />

      Or since the dependency keyword is deprecated long time  <REQUIRE NAME="Alien-Sisyphusion-Gtk2WebKitdlls" />

      Then later in Alien-Sisyphusion-Gtk2WebKitdlls.ppd

      <SOFTPKG NAME="Alien-Sisyphusion-Gtk2WebKitdlls" VERSION="0" DATE="2 +017-03-28"> <ABSTRACT> Extra DLLS for Gtk2::WebKit </ABSTRACT> <PROVIDE NAME="Alien::Sisyphusion::Gtk2WebKitdlls" VERSION="1.3"/> <IMPLEMENTATION> <CODEBASE HREF="http://www.sisyphusion.tk/ppm/x86/Gtk2-WebKit-dl +ls.tar.gz" /> </IMPLEMENTATION> </SOFTPKG>

      And maybe in Alien/Sisyphusion/Gtk2WebKitdlls.pm you list the urls/files/versions... or not:)

        Why not a simple dependency on Alien-Sisyphusion-Gtk2WebKitdlls

        I considered that with another issue a year or two ago (when BrowserUk suggested much the same thing) - but I found that Strawberry's PPM utility took no notice of the "REQUIRE NAME" entry. So I canned the idea without giving it much more thought.
        Tonight I discovered that Strawberry's PPM does however honour the "DEPENDENCY NAME" entry. (I guess Strawberry's ppm is not modern enough to know about "REQUIRE NAME".)

        So ... I 'll =~ s/REQUIRE NAME/DEPENDENCY NAME/g in the PPD files and package.xml, and go with the approach you've suggested. Thanks !!
        Might get a bit messy with AciveState perls if they decide to make "DEPENDENCY NAME" obsolete. They haven't done that yet, have they ?

        Cheers,
        Rob