Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re: What is the best way to install CPAN modules on Debian?

by mpeever (Friar)
on Mar 26, 2009 at 14:48 UTC ( [id://753422]=note: print w/replies, xml ) Need Help??


in reply to What is the best way to install CPAN modules on Debian?

I've had similar problems with OpenBSD. And Solaris is even worse, as it doesn't come with a C compiler.

I tend to favour the dual Perl approach, but I largely work in a server environment. As you have pointed out, that makes a huge difference: code (whether Perl or otherwise) is not so much run on a server as it is added. It's trivial to start a script with #!/usr/local/bin/perl on a server. It gets enormously harder when the script is to run on machines outside the sysadmin's (or the sysadmin's team's) control.

A solution I have commonly seen is to simply not use CPAN modules. I know that goes against all the "best practices" ever published; but several sysadmins I know have decided it's better to re-invent the wheel than to jeopardize a running system with 3rd-party code that typically comes without warranties. In fact, one friend of mine is a sysadmin in a finance company, and there are policies in place explicitly forbidding the use of CPAN modules.

I hate to say it, but there is a lot of merit in that approach. And if there are issues with distributing code across a number of machines because of CPAN dependency issues, re-inventing the wheel is a very reasonable option.

I've moved to a much more relaxed environment (and the lower pay that goes with it) in the last 8 months. It's been nice to use CPAN again without having to justify it to everyone and their dog.

Replies are listed 'Best First'.
Re^2: What is the best way to install CPAN modules on Debian?
by ikegami (Patriarch) on Mar 26, 2009 at 15:14 UTC

    In fact, one friend of mine is a sysadmin in a finance company, and there are policies in place explicitly forbidding the use of CPAN modules.

    We have a ban on modules we can't receive from Debian's package manager, so I take the CPAN module and drop it into my project. Now it's no longer a CPAN module :) I work on projects used internally, so the license is not an issue.

    This way, we test against the same version of the module that ends up being used. It also gives us the ability to make and track changes to it, if need be.

      We have a ban on modules we can't receive from Debian's package manager, so I take the CPAN module and drop it into my project. Now it's no longer a CPAN module :) I work on projects used internally, so the license is not an issue.

      This way, we test against the same version of the module that ends up being used. It also gives us the ability to make and track changes to it, if need be.
      This sounds like a good, simple solution, but isn't it a bit of a problem that the CPAN module can't receive any updates unless you decide to apply them? It takes the process of doing updates out of the domain of the sysadmin's and leaves them up to the programmers.

        Why would the sysadmins be upgrading modules? Assuming there is a need or desire to ugprade, it's up to the programmers to test how the new version of the CPAN module works with their application. Once everything is ok, all the programmer needs to is the drop the new version of the CPAN module's dist into their own dist. The sysadmin can still be in charge of installing this (combined) distribution if so desired.
Re^2: What is the best way to install CPAN modules on Debian?
by Porculus (Hermit) on Mar 27, 2009 at 08:30 UTC

    one friend of mine is a sysadmin in a finance company, and there are policies in place explicitly forbidding the use of CPAN modules.

    I hate to say it, but there is a lot of merit in that approach.

    No, really, there isn't. Wherever possible, risks should be managed, not simply avoided. And CPAN is a manageable risk.

    A policy that does have merit is "no unaudited CPAN modules". It makes sense to control the code coming into your systems; it makes sense to check the licenses and to perform due diligence in (for example) looking at the bug trackers, reading module reviews, looking over the code for nasty smells, and finally installing the code on a development server and checking that it isn't likely to break anything in the operational environment. And, of course, it makes sense to require people to present a good business case before you allocate the resources to do all that work.

    It does not make sense to automatically reject all third-party code. You will waste time and money reinventing wheels. Has that place seriously even written their own versions of stuff like DBI?! If so, they'll have ended up with something that probably contains more bugs, performs worse, and behaves differently from the standard interface that everyone else in the world uses. And to this day they'll be wasting even more time and money maintaining it themselves, instead of letting other people take care of that while they put all their resources into doing their core business well. This is not the path of merit.

      It does not make sense to automatically reject all third-party code. You will waste time and money reinventing wheels. Has that place seriously even written their own versions of stuff like DBI?!

      I'm only passing on what I've been told... It's hard to imagine a profitable company in an extremely competitive and fast-paced business that doesn't have a protocol for working around policies where they are counter-productive. I assume there is a process in place whereby CPAN code can be vetted, tested, approved, and added to some sort of whitelist.

      The immediate effect on my friend, however, is that he can't search CPAN whenever he runs into a wall with his Perl. When he calls to bounce ideas off me, he generally adds the caveat: "I can't use CPAN."

      If we imagine a company with even the most stream-lined vetting process, we still end up with a scenario where a sysadmin's one-off monitoring script becomes a several week effort while he waits for approval for that module. Home-rolling is faster. Even with intense testing and debugging, it'll get the code across the finish line before a module passes review; and a sysadmin doesn't care about portability: the code she is writing has to run on a very specific platform. That removes a huge amount of effort that goes into anything on CPAN.

      People in that environment aren't writing frameworks. As far as I know, neither my buddy's employer nor I have ever advocated re-writing a generalized framework like DBI. That's what Paul Graham calls a "pathological edge-case."

      In a case where sensitive data is potentially exposed, or where loss of service is measured in millions of dollars per hour, the loss of developer and/or administrator time re-inventing a lot of wheels is negligible by comparison. Additionally, in-house code doesn't have to be portable: operating platforms are concretely known and change very rarely.

      From a coder's perspective, using 3rd-party modules makes a lot of sense. But there are business scenarios where it's just not the right thing to do. And in some cases, it's been decided to reject foreign code by default for very sound business reasons. That's my only point.

Re^2: What is the best way to install CPAN modules on Debian?
by JavaFan (Canon) on Mar 26, 2009 at 16:26 UTC
    And Solaris is even worse, as it doesn't come with a C compiler.
    SUN no longer ships gcc with Solaris 10? Are you sure? It may not be installed by default, but SUN used to ship a set of GNU software on their Solaris installation CDs, including gcc.

      You are correct in thinking that Sun does still ship gcc with Solaris 10 and it can be found on the "Software Companion" CD. The version is 2.95.3 which is hardly recent but you can find version 3.4.6 on http://www.sunfreeware.com/.

      Cheers,

      JohnGG

      Doh! I forgot the GNU companion CD. I always use http://sunfreeware.com/ instead.

      Still, I've had issues getting the installed Perl to play nicely with gcc on Solaris. I just started building a parallel Perl system under /usr/local when I set up new systems. Is it just me? I've booked a lot more time on Solaris 8 & 9 than 10, so perhaps my information's outdated.

        For Solaris systems where I don't have access to the SUN compiler, I typically install Perl somewhere (/opt/perl for instance), and just link /usr/bin/perl to /opt/perl/bin/perl. I then compile using gcc.

        Actually, I've often done the same if I do have access to the SUN compiler.

        Solaris shouldn't break down if you replace /usr/bin/perl, and I've never experienced any problems by doing so.

        But this thread was about Debian, not Solaris.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://753422]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others learning in the Monastery: (3)
As of 2024-03-29 04:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found