Good day Gregory,

The problem with that is that not all perl modules are created with the
same license; for practically all, they can be used freely, but some have
limits on how they can be distributed.  That precludes the all-in-one
approach.

The other alternative is that OpenSRS develop everything itself.  That's
feasible, but in doing that, you will get a *much* longer development
time, so things like the .info/.biz launch could have taken quite a bit
longer to get ready, or they would have to increase the size of their
devlopment team (increasing the costs of domains appropriately).  Also,
personally, I would much prefer some things to be 'standard' modules,
particulary any of the crypt modules; somethings that's much more
widespread would have more people looking into the code; much more likely
that there aren't going to be any glaring holes in the cryptographic
system in an open system than a closed one.

By the way, there are a couple of things that you can do, in order to
prevent needing multiple copies of modules being installed.  First off, if
you do have root access to the system where they are installed, you can
install the modules globally to the system (this is the default actually),
so you will not need to re-install them with each new version that comes
out.  The other option, if you've not got root is to install each module
to a specific directory, using the format:
  perl Makefile.PL prefix=/home/httpd/perllib

or similar (practically all modules will allow a prefix option), and then
in the OpenSRS.conf file, put something similar to the following on a
blank line:

use lib "/home/httpd/perllib";  # as from example above.

As the modules don't often change (and when they do, it's usually only
internally, the use is the same), you should not need to update any of the
modules when you move to a new version of the client scripts.

Take care,
Mark.

On Mon, 9 Jul 2001, Gregory Neil Shapiro wrote:

> chuck> That's not a package included with OpenSRS - that's HTML::Template,
> chuck> which is a different module, that you'll have to install (from CPAN,
> chuck> or elsewhere).
> 
> Perhaps there should be some consistency for this.  It seems some the user
> needs to obtain (Crypt::Blowfish or Crypt::DES, Digest::MD5,
> HTML::Template, Storable, XML::Parser) and some come with the OpenSRS
> client distribution (Crypt::CBC, Date::Pcalc, Locale::Country, cgi-lib,
> etc).
> 
> Given a vote, I'd vote to make it all user-install and not include other
> people's packages in the OpenSRS client.  Having multiple copies of things
> hanging around scares me.
> 

Reply via email to