Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

yast vs cpan

by elnino2007 (Novice)
on Nov 09, 2006 at 16:13 UTC ( #583139=perlquestion: print w/replies, xml ) Need Help??

elnino2007 has asked for the wisdom of the Perl Monks concerning the following question:

Hello. Hi. I'm very new here, I hope this is the right place. I'm running SUSE10.1, and I notice that there are a bunch of perl mods listed under yast. Are these some of the same modules that I can install via CPAN? Will Yast see what CPAN installs and vice versa? If not, do they install differently, and cause problems, or do they stomp over the same install locations? Hope that makes sense. Thanks! LN

Replies are listed 'Best First'.
Re: yast vs cpan
by Fletch (Bishop) on Nov 09, 2006 at 16:30 UTC

    More than likely they'll install to the same locations, so yes there could be problems if you try to install the same modules different ways.

    Pros and cons would be:

    • Using the OS' package management would give you an uninstall mechanism
    • It may be slightly easier to use the OS' package manager to install the same set of packages on large numbers of machines
    • You're likely to get more timely updates to packages going straight from CPAN (i.e. you're at SuSE's mercy waiting on them to package a new release; or you'll have to roll your own local package)
    • You're likely to get a wider selection of modules straight from CPAN (you may need Some::Obscure::Module that isn't going to be packaged because there's 7 people on the planet using it)

    There's probably more, but that gives you some sort of an idea. It's similar to any other "use OS' package management" versus "compile from source myself" decision.

    Update: Very good followup below by Anonymonk, especially the one about compilerless boxen.

      To add to your excellent points
      • CPAN can only solve dependencies on other CPAN modules. The package manager of your OS can solve other dependencies as well (a C library for instance).
      • The package manager or your OS (well, at least most of them) can list which files belong to a certain package, and, given a file, list to which package it belongs. That's much harder with CPAN.
      • The package manager of your OS will usually have pre-compiled binaries available (XS modules in case of Perl). Installing from CPAN requires compiling XS modules yourself. Usually not a problem, but it might not work out of the box. Also, you might have servers that don't have developer tools installed (like a C compiler).
      • The package manager of your OS may check certain resources first, for instance whether you have enough disk space to install something.
      I'm not suggesting one should use CPAN or that one should use the package manager of your OS. I'm not consistent either - on some boxes I use CPAN. On others, I use the package manager of the OS. And on some boxes, I use the package manager of the OS, RPMs (which isn't the native package manager of that OS), and install CPAN modules manually.
Re: yast vs cpan
by tweetiepooh (Hermit) on Nov 09, 2006 at 17:15 UTC
    I use CPAN(PLUS) on Suse10.1 64 bit.

    My reasons some of which have already been mentioned.

    1) CPAN will be aware of modules installed by YAST but not visa-versa. ie YAST will update the Perl module list but CPAN not the YAST install list.

    2) More modules in CPAN, probably later versions (see what CPAN wants to update).

    3) Maybe even get a better module to do the same task.

    4) More control if you build it yourself. Get the options you want.

    5)What if YAST update decided to update a module that then broke your proggy?

    6)It's more fun to get and build with CPAN/CPANPLUS, especially when it doesn't always work and you have to delve to sort it out. You can learn a lot that way.

      wow, this list is alive and well. Thank you for the responses!!! Another related question, if I choose to use yast, is there a url I can add to my installation sources to get the latest and greatest (and even additional) perl mods from cpan? Thanks!

        No, 'YaST' and CPAN are not in sync. You will probably be stuck with the Perl modules that were packaged at the time the distribution release was made unless you install from CPAN. Personally I freely upgrade any of the perl module packages that came with the OS distribution, but there again I also have several other perl builds on the machine.


Re: yast vs cpan
by jbert (Priest) on Nov 09, 2006 at 18:54 UTC
    The way I handle this is to use the system packaging tools (yast in your case, apt in mine) to install the distro's packages if possible.

    If the module I need either isn't packaged by the distro, or if I want a newer version, I install via cpan, but as my own non-privileged userid.

    When you run CPAN as yourself, the questions tell you how to provide additional args to 'perl Makefile.PL' (PREFIX=foo) or 'Build.PL' (--install_base foo) to install in your home directory. I tend to put things in $HOME/install/perl.

    Then you tell your shell to tell perl (when run as you) to find these modules:

    export PERL5LIB = $PERL5LIB:$HOME/install/perl/share/perl export PERL5LIB = $PERL5LIB:$HOME/install/perl/lib/perl
    and you can then have the best of both worlds. This won't allow other users (e.g. whatever userid your web server runs as) on your box to run the modules, but you can fix that by setting PERL5LIB to refer to your homedir install in that environment too (and check the file permissions work out).

    This also works nicely in the multiple-machine one-NFS-homedir setup.

      wow, you guys are fast. jbert, these are for the webserver, so, in that case what would you do?
        Hmmm....probably as described. Using the distro packages as far as possible helps keep you up to date on security fixes etc (as long as you are running your update commands).

        If you *do* need something not packaged by your distro, set up a localised install tree as described above. I'd probably create a user 'cpan' to own it and install the modules to its homedir. If I was very paranoid, I'd actually install to /home/cpan/install/perl, check everything worked and then copy (rsync) the ~/install/perl to wherever I had configured the web server to pick them up from (somewhere not under your document root, obviously).

        Note: you generally don't set environment variables for CGIs etc in .bash_profile for your web server user, but how you do it is web-server specific. The apache docs cover setting env vars pretty well.

        Have fun and good luck.

Re: yast vs cpan
by BaldPenguin (Friar) on Nov 10, 2006 at 01:01 UTC
    Because a distro, any distro, normally creates packages that relate somehow to other packages, even the perl package sometimes, I normally seperate my programming environment from the systems.

    I install perl (from and any supporting modules to another location, as an example '/opt/local'. Then running CPAN (or CPANPLUS) using that perl installation, will install all the modules into /opt/local/lib.

    At that point I can update my libs without any effect on the system and vice versa. Just be sure all of your scripts start with #!/opt/local/bin/perl.

    Everything I've learned in life can be summed up in a small perl script!
Re: yast vs cpan
by nicholasrperez (Monk) on Nov 09, 2006 at 21:17 UTC
    Your question depends on a lot of factors, mainly, is this a development box? Is this your home account? etc.

    Personally, I roll my own perl and cpan what I need so I have a very clean (well, clean enough) development environment that is completely separate from the operating system's idea of what it needs. Sometimes when you are supporting existing code, you need your environment to match as closely to what existed when you released. If you are like me and like to keep your OS updated weekly to catch patches and new features, you soon realize that using the OS to manage your perl installation can be hazardous.

    Linux distributions in general apply patches to the things they use internally. This includes perl modules. That means bad things can happen if you rely upon a certain behavior in a certain module, and the distro maintainers pull the rug out from under your feet with a patch.

    It really doesn't require that much effort to compile perl from source with a prefix that points to a location separate from the rest of the OS (ie. in your home directory with your exec path set to ~/bin or whatever). This way in a multi-user environment two users can require two different versions of a particular module with the operating system requiring a third and if they all have their own space, everyone is happy.
Re: yast vs cpan
by xorl (Deacon) on Nov 09, 2006 at 20:37 UTC
    Boycott SUSE (eh I'm a deadrat guy anyway).

    That said, I'd go with the OS package management system for whatever modules it has. You will avoid any annoying CPAN dependencies and know for sure that it will just work for your system.

    As mentioned in other comments, doing this you are kinda at the mercy of the folks who develop the packages to get them out quickly after a new version comes out on CPAN. However, unless you need the newest version or something weird, the benefits usually out weigh the problems.

Re: yast vs cpan
by blazar (Canon) on Nov 09, 2006 at 21:29 UTC
    Hello. Hi. I'm very new here, I hope this is the right place. I'm running SUSE10.1, and I notice that there are a bunch of perl mods listed under yast. Are these some of the same modules that I can install via CPAN? Will Yast see what CPAN installs and vice versa?

    This is a kind of question that comes out quite often, either in the context of some distro community, or in a Perl-related one, with an overall preference for the particular distro's package tools in the former case and for CPAN in the latter, not surprisingly. Indeed, there are advantages to both approaches, as has been discussed here too. Now it seems to me that nobody has mentioned CPANPLUS yet, which supports creation of packages of one's choice through the cpan2dist tool: not all distros are targeted yet, but many "major" ones are, and it shouldn't be too difficult to add others, although I've not really investigated it yet. This makes for great news, since to some extent it "saves the best from both worlds!"

A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://583139]
Approved by ww
Front-paged by andyford
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (5)
As of 2023-03-31 12:38 GMT
Find Nodes?
    Voting Booth?
    Which type of climate do you prefer to live in?

    Results (75 votes). Check out past polls.