[lug] hyperbolic sin() {was: (not)Using CPAN}

[Rob Nagler]

Hi Tom,

> Even if you're trapped in a vendor-locked platform-homogenous
> "Come-Back Inn" environment as some of you may be, your vendor's ideas
> of what you should--or should not--have on your system will almost
> certainly prove unacceptable to an active Perl development team.

False by counterfact.

We're an active Perl shop.  That's all we do.  We turn away anybody
who doesn't want a solution based on bOP, and we've got more work than
people.  We produce state tax returns, federal tax returns, handle
balloting for the 802.11 folks, help couples get married, encourage
kids to walk or bike to school, process insurance data, support
companies with our own CRM system, help technical consortia manage
themselves (blade.org, mipi.org, etc.), and a few other applications I
won't bother with.

We use a few modules from cpan.org.  We have a single RPM spec file
which takes the CPAN source from our CVS tree, runs Makefile.PL, make
install, and does a find (removing cruft like *.bs, .packlist, and
perllocal.pod) to create a files list acceptable to rpmbuild.  That
RPM is installed on all our systems, in a staged deployment,
dev-test-prod, just like we do with all our software and
configuration.

By doing so, we get a few indispensable advantages over CPAN.pm:

* We can ask what files were installed by a specific module:

    rpm -ql perl.modules

* Whence file?

    rpm -qf /usr/lib/perl5/site_perl/5.8.5/Bivio/bOP.pm

* What packages were installed by bivio?

    bivio release list_installed bivio

* And, woops, we need to backout version 8.31 of bOP to 8.30:

    bivio release -force install Bivio-bOP-8.30-1.rpm

In Keeping with the Perl Way(tm), we're also lazy so when we deploy a
new application, instead of creating a Makefile.PL, we check in a file
(e.g. perl-app-freiker.spec) to CVS:

    %define perl_root Freiker
    %define perl_exe_prefix fr
    _b_release_include('perl-app.include');

Then we say:

    bivio release build perl-app-freiker

And out comes an RPM, which can be deployed to dev-test-prod, just
like all our other RPMs be they written by us or somebody else.

We do a lot of other things quite differently than what Perl Gurus(tm)
recommend, and nobody at bivio finds them unacceptable, in the
slightest.  In fact, we sometimes think that our way of programming
Perl has significant advantages over the standard way.

Always remember: There Is More Than One Way To Do It!  And, Rob's
corollary: Some ways may be better than yours(tm).

Cheers,
Rob