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.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I recently thought of installing Padre on the most recent CentOS (which, in case you didn't know, is a community supported enterprise version of Red Hat Linux). The huge number of modules that need an upgrade is discouraging: it wants to upgrade 24 modules (and install 81 more), even after I already installed Wx.

    The main problem I have with that is that I don't want to change anything in the system Perl, as this is contrary to the spirit of CentOS: don't upgrade anything that is stable, as the upgrade might break stuff.

    What I want is to "upgrade" these modules only for Padre, i.e. locally.

    Now what dagolden [perl.org] already mentioned [perl.org] would easily solve that problem: CPAN should be set up to install locally, i.e; not modifying the system libraries, by default, or at the very least, provide a painless option to do so.Having to mess with arguments for Makefile.PL with sometimes dubious, or at the very least, unpredictable results [dreamhosters.com], is not the best imaginable solution.

    p.s. I recently upgraded Padre to the newest version on Windows, and again, it wanted to upgrade tens of modules. Is that really necessary? It's so bad, eh, there are so many of them that CPAN almost chokes, that I almost skipped the upgrade.

    • Often the new modules are needed.

      There's a lot of work "on Padre" that actually goes into various dependencies, resulting in new releases and thus new dependencies.

      The ORLite family alone has gone through 10-20 releases to add embedded database features that Padre needs.

      0.56 was a bit more aggressive than most, since it bumps Module::Build and ExtUtils::MakeMaker to current, had some ORLite upgrades, and a few other minor things.

      Some releases are worse than others, but it's our preference to push developmen

    • We are aware of the fact that it is difficult and time consuming to install Padre from source hence we are encouraging the downstream distributors to include Padre and its major plugins.

      In order to allow you to use the latest (or almost latest) Padre on Linux we also have an experimental version of it that includes everything you need - even a threaded Perl.

      See the Linux section on the download Padre [perlide.org] page.

      --
      • Interesting approach — if only it worked... It turns out not to be so easy.

        I tried the "experimental" "Padre Stand Alone for Linux", but it immediately died, complaining about an incompatibility between Wx and libstdc++.so ("GLIBCXX_3.4.9 not found").

        Anyway... Do you see this approach as a solution for all big projects in Perl? Building all these binary distros seems like a lot of work to me. Plus, with several projects, you get a lot of separate file trees, with possibly a lot of overlap. That may

        • I am not surprised it did not work - I tested it only a very limited number of platforms. (Namely 1) but still I am sorry to hear that.

          As I understand in order this to work we need to build a statically linked perl and wxwidgets and apparently this was not the case.

          I think this can be one approach though I hope this could lead to a package similar to Strawberry Perl Professional but for Linux and similar OS-es which would mean other desktop application could use it as a platform.

          I still think inclusio

          --