Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Red Hat Software Businesses Perl Programming

Perl Modules as RPM Packages 207

Posted by michael from the my-own-catapult dept.
libertynews writes "KPLUG President Kevin Pedigo has just announced his latest project -- RPMPAN, an archive of CPAN Perl modules in RPM format, generated nightly."
This discussion has been archived. No new comments can be posted.

Perl Modules as RPM Packages More

Perl Modules as RPM Packages

Comments Filter:

  • perl with RPM lovin' ? (Score:5, Funny)

    by imag0 ( 605684 ) on Saturday August 23, 2003 @01:32AM (#6771291) Homepage
    I can see where this can go wrong...

    # rpm -i myperl.rpm

    warning: libsomeshit.so not installed

    # rpm -i --force myperl.rpm

    warning: libsomeshit.so not installed

    # rpm -i --force --nodeps myperl.rpm

    segfault. core dumped.

    # rm -rf /

    • Re:perl with RPM lovin' ? (Score:5, Funny)

      by Aliencow ( 653119 ) on Saturday August 23, 2003 @01:37AM (#6771306) Homepage Journal
      It's more like:
      # rpm -Uvh myperl.rpm
      warning: libsomeshit.so not installed
      # rpm -Uvh myperl.rpm someshitlib.rpm
      warning: libXML is missing
      # rpm -Uvh myperl.rpm someshitlib.rpm libxml.rpm
      warning: mozilla is missing

      Then you go berserk. You mirror rpmfind, rpm -Uvh *.rpm, end up with multiple versions of crap in different places, and corrupt the UNIVERSE.

      • Re:perl with RPM lovin' ? (Score:5, Insightful)

        by cowbutt ( 21077 ) on Saturday August 23, 2003 @03:17AM (#6771559) Journal
        Then you go berserk. You mirror rpmfind, rpm -Uvh *.rpm, end up with multiple versions of crap in different places, and corrupt the UNIVERSE.

        I know you're exaggerating for dramatic effect, but therein lies your problem. If you're installing random packages from rpmfind.net, you deserve everything you get. Either stick to packages in your distro's native format and created for the version of the distro you're running (errata, install discs, freshrpms.net in that order) or build your own, newer packages, using your distro vendors src.rpms as a template.

        If you do this, I promise you'll encounter zero problems.

        Too many people think that RPMs are magically some kind of universal package. They aren't and were never intended to be.

        --

        • Either stick to packages in your distro's native format and created for the version of the distro you're running (errata, install discs, freshrpms.net in that order) or build your own, newer packages, using your distro vendors src.rpms as a template.

          See, this is why I never liked package management for other than the base system (like, say, how Slackware does it). Sooner or later I'm going to need some version of some program that's not supported by the package maintainers of my OS, and then I'm off 'rol
          • The problems occurs because software developers are not doing any packaging but the distributors are.

            If the basic packaging system was used by developers too this would not be a problem.

            Of course, establing one standard will take some time. Especially since different distros package things in slightly different ways.
          • Just because a distro provides sophisticated package management, doesn't mean you need to use it. There's nothing to stop you doing 'make; make test; make install' under RH or any other distro, but it's unreasonable for you to expect that the package management database is fully aware of what you've done.

            Personally, I find managing all my packages with RPM useful (things like rpm -e, rpm --verify, rpm --checksig, rpm -qif `which foo` - I have 1321 packages on my workstation which I would hate to have to m

      • # (apt-get|yum) install myperl

        The following packages will be installed:
        myperl, libsomeshit, libXML, mozilla
        Need to get n MB of archives.
        Do you want to continue? [Y/n] y ....

        And then the packages are installed, and you live happily everafter.

    • -1 Troll (Score:5, Insightful)

      by danyoung ( 543350 ) <danielmyoung@gmail.com> on Saturday August 23, 2003 @01:56AM (#6771365) Homepage
      # rpm -i myperl.rpm warning: libsomeshit.so not installed

      Uh, I'd just do:

      # yum install myperl.rpm
      Resolving dependencies
      libsomeshit-1.0 needs be installed. OK? (y/n)?
      What's the problem again?

    • Re:perl with RPM lovin' ? (Score:4, Informative)

      by Anonymous Coward on Saturday August 23, 2003 @03:26AM (#6771579)
      Oh yeah, like any other package system is different. You want to experience the same fun on FreeBSD? Try the following which I did last week:

      portinstall -v p5-DateTime-Format-ISO8601

      Pretty innocent right? I mean what the fuck is involved in parsing dates? The library *I* wrote to parse an ISO8601 subset was about two pages long. You know, dates/times like '2003-05-24' '05-25' 'T12:23:45Z' etc.

      Well, after a "little while" here's what it pulled in:

      p5-Archive-Tar-1.03
      p5-Attribute-Handlers-0.78
      p5-Class-Factory-Util-1.4
      p5-Class-Singleton-1.0 3
      p5-Compress-Zlib-1.22
      p5-DateTime-0.16
      p5-Dat eTime-Format-Builder-0.75
      p5-DateTime-Format-ISO8 601-0.03
      p5-DateTime-Format-Strptime-1.0302
      p5-D ateTime-Locale-0.03
      p5-DateTime-TimeZone-0.25
      p5 -ExtUtils-ParseXS-2.02
      p5-File-Find-Rule-0.11
      p5 -IO-stringy-2.108
      p5-Module-Build-0.19
      p5-Number -Compare-0.01
      p5-Params-Validate-0.64
      p5-Pod-Esc apes-1.03
      p5-Pod-Simple-0.96
      p5-Test-Builder-Tes ter-0.09
      p5-Test-Harness-2.28
      p5-Test-Pod-0.95
      p5-Test-Simple-0.47_1
      p5-Text-Glob-0.05
      p5-Text- Tabs+Wrap-2001.0929
      p5-Time-Local-1.07
      p5-YAML-0 .35

      Can't wait to install some of these Perl RPMs on my Red Hat box........ (in this sentence, "can't wait" means "I'm not going to fucking touch this crap")

  • Huh? (Score:5, Insightful)

    by eln ( 21727 ) on Saturday August 23, 2003 @01:33AM (#6771294)
    How hard is it to install CPAN modules in the first place? This seems like a solution without a problem to me.

    Maybe if it were easier to navigate than true CPAN, but according to that page, the way to find your module is by the first letter of that module. So what happened to browsing modules by category? This thing is useless if I need a module for a specific purpose, but I don't know the name of the specific module I'll need.

    So, not only are they converting Perl modules to a format they don't really need to be in, but they're making the thing harder to use than CPAN is already.

    • Re:Huh? (Score:4, Insightful)

      by Aliencow ( 653119 ) on Saturday August 23, 2003 @01:39AM (#6771314) Homepage Journal
      I find it practical to have everything on the system as the same type of packages. It makes it easier to manage dependencies and updates...

    • Re:Huh? (Score:3, Insightful)

      by Micah ( 278 )
      No real disagreements, but it *is* nice to have this sort of stuff managed by your package manager.

      • Re:Huh? (Score:5, Informative)

        by jsprat ( 442568 ) on Saturday August 23, 2003 @01:56AM (#6771364)
        it *is* nice to have this sort of stuff managed by your package manager.


        Yes, it is. Check out cpan2rpm [cpan.org].

        The best of both worlds - modules built locally, with rpm ease of installation and de-installation.

      • Re:Huh? (Score:2, Insightful)

        by hetta ( 414084 )
        No real disagreements, but it *is* nice to have this sort of stuff managed by your package manager.

        Except that there need to be different rpms for RedHat, Mandrake, SuSE ... and for different versions of those distros. What's the probability that this archive will track all of that? 10 %? Lower?

        Really, the cpan setup keeps track of its own dependencies, and gives you flippant comments like "yep, it's a nice idea to include this if you actually were to wish to use that" to boot. No rpm setup can get clos

        • Re:Huh? (Score:2)

          by Micah ( 278 )
          > Except that there need to be different rpms for RedHat, Mandrake, SuSE ... and for different versions of those distros.

          Not necessarily. Perhaps a different set for each version of Perl. Perl has a pretty standard location for this type of stuff, across distros, I THINK. /usr/lib/perl5/site_perl/5.8.0/ It's the same at least on Red Hat and Gentoo.

          > No rpm setup can get close to that.

          Maybe not rpm. Apt and ebuild would do it. :)

    • Re:Huh? (Score:4, Interesting)

      by NightSpots ( 682462 ) on Saturday August 23, 2003 @01:58AM (#6771374) Homepage
      Two things:

      1) CPAN isn't flawless: yesterday, I tried using it to install File::Temp and it tried upgrading perl from 5.6 to 5.8. That simply isn't the correct thing to do, under any circumstance.

      2) Having used FreeBSD, which has perl modules in the ports/package system, I can absolutely say that it's a nice thing to have. Being able to pkg_add a perl module in half a second, no compile time, no dependency hell, it's a good thing.

      • Re:Huh? (Score:4, Informative)

        by Bluetrust25 ( 647829 ) on Saturday August 23, 2003 @03:17AM (#6771560)
        > 1) CPAN isn't flawless: yesterday, I tried using it to install File::Temp and it tried upgrading perl from 5.6 to 5.8. That simply isn't the correct thing to do, under any circumstance.

        I've found through experience with just this very thing that the first command run through CPAN should be:

        perl -MCPAN -e shell
        install Bundle::CPAN

        Upgrading to the newest version is necessary to get it to leave perl the hell alone.

        So once you get past that hurdle, I find the worst part about CPAN is that some packages which everyone uses like mod_perl, DBI, and DBD::mysql fail to install unless Apache was compiled the correct way and currently running, or MYSQL is running and allows some bullshit nameless user to access all databases (!)

        In RedHat Linux 7.x (maybe 8.x and later too), the mod_perl RPM is installed by default, but Apache isn't compiled correct to play nicely with it. So if you want to actually use mod_perl's features (i.e. install Bundle::apache in CPAN) then you have to uninstall apache and compile it by hand.

        Frustrat-o-rama.

        But in general, CPAN rocks. If it wasn't for CPAN then perl wouldn't be as popular as it is today. Why, just earlier this evening I was thinking that I'd love for users of a web app I'm working on to be able to import data from Excel files rather than just comma-delimited, I did a quick search at search.cpan.org and WHAM, one 'install Spreadsheet::ParseExcel::Simple' later and now users can upload Excel files. I can't think of any other language that makes it this easy to find and reuse libraries.

        CPAN makes me look like I'm really good at what I do.

        • Re:Huh? (Score:2, Interesting)

          by jonadab ( 583620 )
          > So once you get past that hurdle, I find the worst part about CPAN
          > is that some packages which everyone uses like mod_perl, DBI, and
          > DBD::mysql fail to install unless Apache was compiled the correct
          > way and currently running, or MYSQL is running and allows some
          > bullshit nameless user to access all databases (!)

          For DBD::mysql, I think you can say no when it asks if you want to
          test. mod_perl is a problem if you don't have the Apache sources
          installed, and IMO the correct solution is to i
          • WHAT THE HELL ARE YOU SMOKING???

            I've installed Apache tons of times without support for mod_perl, and let me tell you unless you are doing a LAMP installation you don't want to think about it.

            Similarly, there are tons of non-perl apps that use MySQL as a backend for various reasons (usually to supplant huge flat configuration files or logs).

            Not everything is webserving, man!

    • Re:Huh? (Score:3, Funny)

      by Ian Bicking ( 980 )
      If you want any programs to be under package control (e.g., Perl applications) it is nice to have their dependencies under package control as well. Otherwise you have to bundle all those dependencies.

    • Re:Huh? (Score:5, Insightful)

      by Anonymous Coward on Saturday August 23, 2003 @02:47AM (#6771509)
      Well, since you are looking for a problem, this is it: We run our servers for 3 years minimum, 5 years ideally. During that time, we may or may not need to do updates (security & bugfixes driving that for the most part). During that time, the server + HW RAID + Backup could fail. During that time, we may need to clone the system. During that time we may have reason to verity the integrity of the files & the system. (You get the idea). During that time you may need to know why the heck file 'foo' is installed on the system, and how to get it to your end user systems (remember, just because it's there doesn't mean YOU put it there - many sites have multiple sysadmins).

      RPMs serve as an excellent way to document what's on the system. As a benefit, you can keep them around and repeat the procedure if needed.

      Imagine for a moment that you have a live production server that NEEDS to be there; you run nightly full system backups, you have mirrored hot swappable hard disks. Now, something goes wrong and you need to rebuild- terribly wrong, all 15 backup tapes were lost, and the mirrored drives are corrupt; it's 3am and you get the page to come into work. Can you put your system together again? That's but one possible scenario.

      Imagine for a moment your sidekick admin, who's since quite, built the system without your knowledge. You need to do that again- what did he do? what's installed? how do you reproduce it? OH, and of course your coworker had almost next to no documentation on what specifically they did.

      Having RPMS isn't about the 'ease of install' - installing the software is easy! It's about the ease of ongoing maintenance & accountability for the system. Debian packages fall into the same category.

      In addition to above, a more familiar way of looking at it; look at all the crap that builds up in windows as you add/remove software. Eventually, you need to reformat, etc. Installing software on Linux is similar.

      3 years down the road... did ...humm... I... arg... install... Time::HiRes?
    • Erm.

      The whole point of this is to make it so that the RPM database can be aware of what software is installed on your system... not to simplify installation.

      If RPM was smart enough to actually go look in /usr/lib/ and see what's there instead of just checking it's own DB and just blankly assuming that if something wasn't installed via RPM it must not exist, then you'd be absolutely right and this would be a solution without a problem.

      And let me know if/when you figure that problem out. You could do some
    • Some (not all) CPAN modules are hard to install. The hardest are always those who involves some C code, that depens on third party libraries.

      Try installing the mysql DBD drivers without having installed the mySQL header files first, for instance. It's not obvious that you need those to get some perl drivers installed.

      Try installing PerlMagick; even with a working ImageMagick installation on your system, it's not straightforward to get PerlMagick up and running.

      There's a whole bunch of modules that alwa

    • Re:Huh? (Score:3, Interesting)

      by juhaz ( 110830 )
      How hard is it to install CPAN modules in the first place? This seems like a solution without a problem to me.

      It isn't very hard to do "./configure && make install" either for normal software, yet we still haver package managers?

      Why, you ask? Because we want to be able to uninstall stuff as well, because we want to have dependencies and because we want everything relating to software installation be handled by one program (apt or yum, for example).

      So, not only are they converting Perl modules t

  • seems a little wasteful.. (Score:3, Interesting)

    by nich37ways ( 553075 ) <slashdot@37ways.org> on Saturday August 23, 2003 @01:33AM (#6771295) Homepage
    Why exactly do they need to do this every night??
    Surely it would be infinetly simpler to just rsync against the server with the CPAN modules and then only rebuild RPMS for new/modified modules.

    You could even use perl to do this...

  • What exactly was wrong with... (Score:4, Insightful)

    by ultrapenguin ( 2643 ) on Saturday August 23, 2003 @01:34AM (#6771297)
    perl -MCPAN -e 'install SomePerlModule'?

    It would get compiled for your system, warning you and/or downloading all the required dependencies.
    • I sort of agree, installing using the CPAN tool is pretty easy. But, I maintain some custom install RedHat CDs that need some PMs not installed by RedHat. I have the user install them using the MCPAN tool, but it sure would be easier just adding them to the list of RPMS for anaconda to install at system creation time.

      I guess it would also be easier for perl developers creating RPMs to bundle these in with their RPMs for a single RPM based install rather than adding instructions for MCPAN.

      I think it is a
      • > I sort of agree, installing using the CPAN tool is pretty easy. But, I maintain some custom install RedHat CDs that need some PMs not installed by RedHat. I have the user install them using the MCPAN tool, but it sure would be easier just adding them to the list of RPMS for anaconda to install at system creation time.

        Yep, since you are already creating custom install cds, I assume you have the knowledge to roll these modules into RPMs yourself. This "script" he uses is using another script (cpanflute2

    • Uninstall? (Score:4, Insightful)

      by jbn-o ( 555068 ) <mail@digitalcitizen.info> on Saturday August 23, 2003 @01:55AM (#6771359) Homepage
      perl -MCPAN -e 'install SomePerlModule'

      CPAN Shell makes installation easy, yes. Now show us what the command for uninstallation is.

      Also, it would be helpful if the CPAN Shell command you'll show us could warn of lingering dependencies (where package A strictly depends on B and if you uninstall B you'll be warned that if you proceed package A will not work anymore).

      • Re:Uninstall? (Score:5, Informative)

        by PghFox ( 453313 ) <afoxson&pobox,com> on Saturday August 23, 2003 @07:19AM (#6772172) Homepage
        CPANPLUS [cpan.org], which is scheduled to replace CPAN.pm in the 5.10 core, has uninstall functionality.

        [root@ocicat root]# perl -MCPANPLUS -e shell
        CPANPLUS::Shell::Default -- CPAN exploration and modules installation (v0.03)
        *** Please report bugs to <cpanplusbugs@lists.sourceforge.net>.
        *** Using CPANPLUS::Backend v0.042. ReadLine support enabled.

        CPAN Terminal> u File::ReadBackwards
        Checking if source files are up to date
        Retrieving /root/.cpanplus/mailrc.2.04.stored
        Retrieving /root/.cpanplus/dslip.2.04.stored
        Retrieving /root/.cpanplus/packages.2.04.stored
        Uninstalling: File::ReadBackwards
        unlinking /usr/local/lib/perl5/site_perl/5.8.0/File/ReadBack wards.pm
        unlinking /usr/local/man/man3/File::ReadBackwards.3
        unlinking /usr/local/lib/perl5/site_perl/5.8.0/i686-linux/au to/File/ReadBackwards/.packlist
        Uninstalled File::ReadBackwards successfully
        All modules uninstalled successfully
        CPAN Terminal>
        Exiting CPANPLUS shell
        [root@ocicat root]#

    • Re:What exactly was wrong with... (Score:5, Insightful)

      by joe_fish ( 6037 ) on Saturday August 23, 2003 @02:56AM (#6771526) Homepage Journal
      From having fought to get Bugzilla installed for about 2 days, most of the time being spent using -MCPAN can say with feeling - everything.

      No uninstall.

      It is yet another package system to learn

      I didn't work without quite a bit of hacking (but perhaps you can blame Solaris for this)

      It isn't exactly a logical syntax, compare perl -MCPAN -e 'install "Foo::Bar"' with apt-get install foo-bar

      And I want the dependency system to work with my systems dependency system, and not in a parallel universe.

      The Java-RPM system over at JPackage.org is good and useful, I hope this will be similarly useful.

      Perl programmers can (and probably will) carry on using cpan, the rest of us can have an easier life when red-carpet or apt-get just does the right thing.

      • I just went through the same thing. And, might I add:
        • When a binary module fails to compile, you have no idea what to do. You're SOL unless you feel like debugging perl's C code; which I don't, because the reason I'm installing bugzilla is because I have my own bugs to deal with.
        • When a module fails its tests, you have no idea what to do. Similarly SOL.

        Lesson learned: never install a binary Perl package with CPAN. Go get the RPM for your distro, and hope it hasn't been EOL'd yet (trying to find RedH

    • Because normally the user doesn't know or care that they want 'SomePerlModule' in the first place, they're just trying to install a package that depends on some .pm file with no obvious relation to the name of the module that provides it.
    • The trouble with perl -MCPAN is not only that it won't let you uninstall easily (as somebody else pointed out) but also that it won't let you install a specific version.

      I'd really like to have a bundle file list version numbers so that when I install the bundle it doesn't fetch the latest version of everything on the planet. Yes, I know it's documented as doing this. But check the source. It's not implemented. EVery time you use a bundle file, you get the latest version of everything which is not alwa

  • Existing RPM's (Score:3, Interesting)

    by rf0 ( 159958 ) <rghf@fsck.me.uk> on Saturday August 23, 2003 @01:34AM (#6771300) Homepage
    OK Excuse me for being stupid but how is this any different from existing p5-Foo-Bar.rpm?

    Rus
  • OK, so this is predicated on the idea that RPM is a better package manager than CPAN...and that your perl setup is pretty much identical to redhat's. Since many (if not most) perl modules don't have c extensions, a binary distribution isn't really that useful, is it? I mean, perl -MCPAN -e shell; install foo works pretty well, and will download and install dependencies for you.

    I guess I'm thick or something, what am I missing here? What's the point?
    • The problem is the usual where the hell did it go, unless you control the destinations it can get splattered all over the place. The problem with rpm is that it assumes a directory structure that is usually different from distro to distro. My perl install on Slackware has different destination requirements, I never use Slacks rpm anyway.

      This is the essential problem with make also. It is getting too hard to keep track of all the destination and dependancy differences that are happening. CPAN is a great so

  • Need the reverse of this (Score:5, Insightful)

    by Julian Morrison ( 5575 ) on Saturday August 23, 2003 @01:40AM (#6771316)
    I use Mandrake and it is So Bloody Annoying to be asked by RPM to install perl module RPMs that I already installed (or updated) via "perl -MCPAN -eshell".

    Not that this is really this guy's problem, but if anyone from Mandrake is reading, please take note. Either there needs to be some magic added to RPM so it treats perl modules as installed RPMs - or else, the dependency checks need to be able to look for the presence of actual modules.

    Having to use --nodeps is both annoying and dangerous.
    • This is the reason for the RPMPan project. You'll be able to install the modules as RPMs in the first place, and software that is not in CPAN will be able to list them as dependencies.

      Sounds like a solution to your problem.

      Alternatively, there's always --nodeps if you're sure.

      • Don't want to (Score:4, Informative)

        by Julian Morrison ( 5575 ) on Saturday August 23, 2003 @02:17AM (#6771426)
        I like the CPAN shell interface.

        - it lets me search, and read the module descriptions (assuming the lazy sod module creator has written one).

        - it lets me check what's out-of-date with a single command ("r"). It automatically keeps in sync with CPAN's module repository. It even updates itself live (install Bundle::CPAN; reload cpan).

        - it doesn't merely install binaries, it runs the compile (so the result is guaranteed to work with my libs, or at least complain sensibly) and often asks for config options.

        - it already does all the dependency stuff that RPM could do, and it does it cleaner and better and in pure perl. It detects actual dependencies rather than merely advertised ones. It can fetch the required modules and install them, without needing to ask.

        - it does all this from a friendly unified command line app that I can run remotely over SSH on a co-lo server.

        - it's in every install of perl (well, Perl-for-Windows is a special case, but that's nothing new).
    • What you suggest is quite a big change to the way RPM (or pretty much any package manager) works. Never mind the special case of Perl modules, you're saying that files installed outside the package manager's control should be usable to satisfy dependencies.

      This might be possible, but one obvious problem is what happens when those files are later removed or replaced. For example, you have fred-1.0 installed by hand and install an RPM package of jim-0.1, which depends on fred = 1.0. Well, perhaps RPM coul
      • "It might be harmful if you do something stupid with it, therefore you mayn't do it at all" is not proper unixy design IMO.

        Your scenario describes one stupid way of shooting yourself in the foot, but it's hardly a unique one. Other similar ones would be: uninstalling with --nodeps, overwriting an RPM with a "make install", overwriting libs with a newer version and "-ivh --force" so as to make new programs load whilst keeping older ones, etc etc.

        Basically, it's a problem that won't bite newbies (becaue the
    • Oh wise and magnificent guru, how you do suggest we do that? Wouldn't want to be lazy, after all.

      Let's assume I just installed relatively uknown perl module uglebugle and C library fdasgfgfa by CPAN and "make install", I didn't, of course, notify package manager about this because it has to be smart enough to deal with them itself. Now our package manager scans a file system and notices few new files, fdasgfgfa.so and uglebugle.pm, of course there's no trace of them in it's package database because they ar
  • CPAN makes it so easy to install perl modules. Why do we need rpms?

    • Re:CPAN == RPM for Perl mods (Score:5, Insightful)

      by akedia ( 665196 ) * on Saturday August 23, 2003 @01:49AM (#6771341)
      There are some cases where a strictly "binary-only" system would be wanted. It is possible to build RedHat servers without GCC and stripped-down C libraries for various reasons, such as really small hard drive, or security (kinda hard for users to compile rootkits if there's no C compilier available).

      CPAN builds the Perl modules in the same way you would on a source-based distro. It downloads the tarball, unzips it, does a
      ./configure
      , checks for dependencies, then does a
      make
      and
      make install
      . RPMS don't require compiliation, and for systems lacking a C compilier, or systems with many Perl modules to install, this can be very useful. Try to imagine downloading and compiling the entire CPAN archive. It would take a week even on a fast system. Let the developers build it on something massively distributed and release an RPM that takes a few minutes to install.
    • Comment removed based on user account deletion

    • Re:CPAN == RPM for Perl mods (Score:4, Informative)

      by juhaz ( 110830 ) on Saturday August 23, 2003 @09:34AM (#6772529) Homepage
      Because perl modules aren't (or shouldn't be) any different from other software and should be handled by same system that handles all the other software?

      Why should we have different database for perl modules than rest of the system? While we're it for perl, why not make one for c, another for c++, yet one for java, then there should be one for python, etc etc. That'd be a frickin' nightmare and best of all those wouldn't have any knowledge of each other, so if my C program depends on perl modules it wouldn't have any way of knowing if it's installed or not because it uses different package manager.

      Thanks but no thanks. I want one thing to keep track of ALL software, no matter what language it's written in.

  • It solves a problem (Score:5, Insightful)

    by cspenn ( 689387 ) <financialaidpodc ... .com minus punct> on Saturday August 23, 2003 @01:44AM (#6771329) Homepage Journal
    I see a lot of posts asking "Why" since perl -MCPAN -e shell is about as straightforward as it can get.

    Obviously, it was created to scratch an itch, so cut the guy some slack. If you don't like it, don't install it. For him, and maybe for others who are new to it all and are just comfortable with one tool, it solves a problem.

    Chris
    http://www.studentplatinum.com [studentplatinum.com]

  • Good idea.. (Score:2, Insightful)

    by vikku ( 79699 )
    I think this is what RedHat and Mandrake users would really like, the trick is probably in keeping all the RPMs up to date. Hope that there is a system that automatically creates RPMs from perl's CPAN module. then all one has to do is "perl -MCPAN -i " and this would download, compile, make a package and install. It would even better to make it package manager independent and add .deb support as well.

  • BSDPAN (Score:5, Informative)

    by Moridineas ( 213502 ) on Saturday August 23, 2003 @01:50AM (#6771342) Journal
    Already like this on FreeBSD systems. Called BSDPAN. Perl can be installed through the ports tree, and upgraded as easily.
    • What BSDPAN actually does seems to be the opposite of this. It's not about the perl modules in the ports tree. The trick is that modules installed with the plain old CPAN module rather than the FreeBSD-specific tools get registered as FreeBSD packages nevertheless, so that you can uninstall them with the pkg*-tools, inspect them with pkg_info etc.
      • Actually I believe it does both things. You can install perl modules via the native perl CPAN interface and they are registered as FreeBSD packages, or you can install a perm module via a FreeBSD package/port.

  • I = Newb ... find RPM = Good .... usually (Score:3, Funny)

    by skogs ( 628589 ) on Saturday August 23, 2003 @01:53AM (#6771352) Journal
    I would definitely consider myself a newb to linux. been playing with it for a few months on and off. Can install them all and get them all working fully now. I can set up my webserver and link up my little homebrew website...I can serve email to myself.

    I'll be honest. I am much more confident with the RPM package manager than the CPAN command you all are saying is so wonderful. Perhaps if I read an instruction book or something...but I don't generally program, so I don't have those books laying around.

    I think its a good idea for newbs that can play around with the scripts and hopefully find something that works. Right now I'm working on learning PHP...but am obviously not competent on it yet.

    It may be redundant for most of you well learned folks...but then so is that damn gui. I bet you all wish the gui didn't load either...since it is so redundant. :)

  • And its great! The best part is that .debs can specify dependencies on perl modules, which can then be met via apt. This has the added benefit of keeping all files under the control of the package manager... instead of floating around in limbo.

    Of course, some of the more obscure modules never get packaged... so if this RPM database proves succesful, perhaps Debian could look into automating the package of all the smaller, less used modules.

    • Even better in Debian (Score:3, Informative)

      by addikt10 ( 461932 )
      Using dh-make-perl, you can automatically grab the latest source for any module on CPAN that isn't already included in the Debian distribution, and make a deb package for it, trivially managing future updates and installation.

      Mmmmmm, Debian

  • Perl on Debian (Score:2, Insightful)

    by penguin7of9 ( 697383 )
    Perl packages have been packaged as Debian packages for quite some time--the package and all dependencies are automatically downloaded and they are automatically kept updated.
  • I'm a little bit confused as to how this is different from Debian's handling of Perl modules? Most any perl package (ie: "Date::Manip") is available as: "lib-perl", like "libdate-manip-perl".

    Since they're Debian packages, you get full dependency upgrades, security updates (ie, for CGI.pm) mostly for free, although I'm guessing you're not going to get all the newest / latest / minor / crappy modules. Is that the only advantage?

    --Robert

  • CPAN blows chunks (Score:2, Funny)

    by Anonymous Coward
    CPAN is banned from the servers I manage, because it likes to sometimes install shit into /usr and overwrite the OS's packaged perl libs. Bear in mind that this is after having edited the config file and pointing to /usr/local as the path to install shit into. Some modules install ok, but others just like to do whatever they want (as opposed to whatever you want). I've made it a rule that nobody with root access is to ever use CPAN to install anything (or else they get to clean up the fucking mess). Sin

  • Good idea! (Score:5, Insightful)

    by Daniel Quinlan ( 153105 ) on Saturday August 23, 2003 @02:34AM (#6771476) Homepage
    A lot of people seem to be really missing the point of this idea and seem to be making what I would call the "waaah! you can't be a real perl hacker if you like this idea" response.

    First, a number of Perl packages already ship in RPM format and are distributed with Red Hat and other RPM-based distributions. This will integrate much more nicely and if package names are chosen well, it will avoid conflicts between CPAN-installed packages and RPM-installed packages. I myself use Debian and always use the Debian package instead of CPAN if it's available. It's easier, it's faster, and (in the case of Debian) you get various fixes that might not have made it into the upstream.

    Once you're using some packages for Perl stuff, you might as well try to get everything in the distribution package format. In addition, I think the more appropriate question is why it's taken so long for someone to think of and then implement this idea. Why on earth would you want to use more than one package management system on your box, especially when CPAN is just for Perl packages. Using CPAN when RPM packages are available might even be silly (provided the packages are well-constructed, I don't know that they will be).

    Plus, the truth is, CPAN is cool and all, but it's not all that great. The usage is bizarre and if an average user isn't a Perl person, then why should they need to learn perl to install some perl-based package that depends on some CPAN modules? CPAN also is just plain inferior to RPM and .deb when it comes to installation, deinstallation, configuration mangagement, upgrades, and just about everything else.

    Now, I just hope they decide to do the same for Debian packages. (Debian provides quite a few already, but more is better.)

    • Not every Linux box has a compiler on it. There *are* people who save the massive disk space and time it takes to install a compiler. If I need Time::HiRes on a machine that has no compiler I'm facing a nasty prospect of building it myself on another machine, hand copying it over and installing it. I could also take the time and disk space to install a compiler that will possibly only ever be used for about half a second. Now I can just install an RPM.

      More than once I've sworn that there weren't RPM's

  • Perl Modules on FreeBSD (Score:2, Informative)

    by Anonymous Coward
    In 5.1-RELEASE at least, the CPAN module is integrated with the FreeBSD package system so that when you install a module via -MCPAN, it also registers in the package database. There are quite a few modules in the ports tree, but it seems easier simply to get the most up-to-date modules off of CPAN and then use pkg_* to deal with uninstalling modules and whatnot. Generating nightly RPMs of the entire CPAN tree seems like a fair amount of overhead. Are there enough uses for this to warrant it?
  • wrapped up in an installer that R eads P rogrammers M inds. HOW WONDERFULLY SUBLIME

  • How to do this in Debian! (Score:3, Informative)

    by GoRK ( 10018 ) on Saturday August 23, 2003 @03:42AM (#6771604) Homepage Journal
    Debian has (for quite a number of years, anyway) had the ability to generate a debian package from CPAN souces with a very very very minimal effort.

    Here's how to do it in three easy steps:

    Step 1: Go to CPAN and figure out what you want.

    Step 2: dh-make-perl --cpan --build --install

    Step 3: There is no step three!

    ~GoRK

  • Oh wow (Score:2)

    by mcc ( 14761 )
    It's like, let's take the two package management systems I hate the MOST and combine them.

    Uggh..
  • I use cpanflute all the time. I haven't built ALL of CPAN using it, but it works for me on every CPAN module I've tried. Simple, clean, quick.

    cpanflute foo.tar.gz ; rpmbuild --rebuild foo-*.src.rpm

    • cpanflute sounds interesting. I'm going to have to remember that (and checkconfig, mentioned earlier)

      Anything that helps you autogenerate RPMS is useful in my mind.

  • Just tried this today. My results. (Score:3, Informative)

    by deathcow ( 455995 ) on Saturday August 23, 2003 @04:55AM (#6771794)

    Apparantly there is a major disconnect between package dependencies and what is actually installed on a box.

    I wanted to add RPC::XML to my Mandrake box, so I tried installing the rpm version. It complained about a list of about 20 failed dependencies, missing packages.

    So I grabbed the tar from CPAN and did the good old make install and it mentioned that only the XML-Parser was missing.

    So... would the rpm have worked if I told it to ignore dependencies, since those perl lib's were already on the box?

  • This is great, for a while I have been using cpan2flute which comes in an RPM from freshrpms [freshrpms.net] to build my own RPMs from CPAN for my RedHat boxen, and this will save me from doing that :-)

    Will there be an apt repository? I hope so :-)

    Also will it be able to cope with ImageMagik -- probably the hardest Perl module to get working in my experience...

  • Bad idea.

    The Perl environment is installation dependant. The location of your siteperl, the C compiler version, the location of your libs, and even the version of your compilor are encoded into the makemaker environment.

    The use of RPM to install modules will require that all distributions follow a standard.

    What if I wnated to install perl 5.8 on /opt/perl/perl5.8 while my production 5.6 in running on /opt/perl/perl5.6?

    What do I do if the RPM binary was built with incompatable paths and compilers?

    Willia

    • Bad idea.

      [...]

      What if I wnated to install perl 5.8 on /opt/perl/perl5.8 while my production 5.6 in running on /opt/perl/perl5.6?

      Then you don't want to use RPMs. But you're an exception; 99% just want to install the packages and expect it to work. Only a few hackers are going to do stuff like that.
  • I dont know , maybe I'm just missing it . But to me RPM is a fairly crappy package management program . The CPAN shell appears to be far supperior , hell it actually works and resolves dependancies . Now I have not used redhat since 7 (except at work were I deal with a hodge podge of systems some redhat , some debain , some misc) , so if rpm has improved vastly please correct me . Otherwise this just seems like a waist o time to me.
  • this made my morning. I work at a strictly Redhat shop, and I do like RPM ( no flames, please, Debian is great, so's Gentoo, so's FreeBSD, but so is Redhat + RPM ), and perl is an excellent way to get things done quickly.
    In the past, I've had problems w/ wanting to use a module, which is dependent on 5 other modules, which is then dependent on 5 more, etc., so I end up building 10-20 RPMs for just 1 module. Which I will have to update sometime in the future...bugger! Which, when under time pressure, ge
  • Besides all good reasons to have CPAN packages managed as RPMs there is on more people failed to mentioned:

    When I ship software to customer on CD, which uses some perl script they expect me to have ALL they need on this CD. Knowing their version of Redhat Linux I can pick and package appropriate CPAN RPMS and be sure that RPM package manager will take care of dependencies.

    Besides (beleive it or not!) there are some computers which do not have internet connection. Some people want to be able to install per

  • Parallel package managers (Score:3)

    by rice_burners_suck ( 243660 ) on Saturday August 23, 2003 @10:01PM (#6775597)
    Herein lies the problem of "parallel" package dependancy managers: Each package system, whether it is RPM, .deb, the FreeBSD ports collection, or any other system, maintains a database of what is installed. This creates the following problems:
    • Once you use a package management system, you are locked into that system.
    • If you use two (or more) different systems, one will not know about the other and you'll end up with an awful mess when you install things with similar dependencies.
    • If you manually build and install some software, the package managers won't know about it and you'll end up with a mess.
    Instead of using a database of some sort in the package manager, why don't the package managers "search" for the proper dependencies? I know it might take significant resources to perform such a search, but it can be narrowed down by a simple configuration file (like /etc/dependencies or something) that tells all package managers where to look for stuff. All the package managers and ports collections out there will agree on some minimal standard and then regardless of the advantages or disadvantages of each system, they'll get along together as far as dependencies are concerned.

    Once something like that takes place, you'll be able to download whichever package format(s) you choose at any time, and ideas like Perl Module RPMs will be a good idea.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close