[Pdx-pm] [csieh at fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl]
Jonathan Leto
jaleto at gmail.com
Tue Aug 26 17:07:19 PDT 2008
Howdy,
Rentrak has many different development projects which each uses it's
own build of Perl on top various internal Perl modules, which may or
may not come from different subversion repos, live on different
filesystems, etc. Each has different databases/minimum module
versions/supported Perl versions/etc. The way we deal with this is:
#!/usr/bin/foo_perl
use TheRightLibs 'foo';
Where TheRightLibs is a simple module which gets the properties
associated with subsystem 'foo' ( stored in another Perl module) and
requires them into the current namespace. This can include fiddling
with @INC, %ENV, whateva'.
Thus, each subsystem has a canonical place where settings can be
changed and no scripts or shebang lines or environment variables need
to be changed. Each subsystem has it's own perl and this is explicitly
used on the shebang line of every script that is part of that
subsystem. If you wanted to change the password or the name of the
database or whatever for every script in subsystem 'foo', all you do
is change the associated properties module and then *poof*, magically
delicious.
I think this method has all of the features you want without the
insecurity of "env perl".
Cheers,
> I couldn't care less about what people with their wits about them do,
> I blame that for the popularity of PHP. I care about what works and
> is programmatic, reproducible, clean, easy to document and understand,
> that -may- have the potential for a security hole but only if there is
> unrestricted access to the application.
--
[---------------------]
Jonathan Leto
jaleto at gmail.com
More information about the Pdx-pm-list
mailing list