Re: it's safe to run a web hosting server with the unstable distributions ?
On Mon, Apr 10, 2000 at 07:15:40PM +0200, Phil Pennock wrote:
> Typing away merrily, John Haggerty produced the immortal words:
> > Is there say a test that can be implimented that would test to determine
> > wheather the program you are running will work under perl<whatever> and
> > then pick that version of perl? That would really rock and would possibly
> > be quite easy considering perl is a great tool for text manipulation and
> > analysis.
> At run-time of request? Erk!
Actually, all of the scripts we maintain do "register" their existence
and location in syslog each time called.
This is not just a perl issue. What about header files, /usr/src/linux
and so forth? What if client linked to libc4 krb4 libs? (No
that is not made up.)
At a certain point, a customer that does NOT want to upgrade is
increasing your costs and complexity. That complexity (and associated
costs) apply to all users. Worst case, imagine the extra expense
caused to 1500 perl users because just one doesn't want to upgrade
from legacy /usr/bin/perl -> perl4 to current. I'd guess that
ASPs might have contracts that addressed this fairly well. Hmmmm.
Anyway, management of legacy code is WAY OT from can you
run "unstable" server. ;^)
> If you're using a web-server which pre-determines mime-types, such as
> wn, you could conceivable use perl_version -c script, making sure that
> you handle -T (taint-checking) on the command-line.
> But if the script is syntactically valid in a version where it would
> actually fail, then your "test" becomes a competent human perl
> programmer. Or non-human, if you employ such.
> The best way IME is to not have /bin/perl exist - always encode the
> version number, and let the #! line be your switch for picking the perl
> Oh, and the boss says that we have a large proportion of 1,500 customers
> of the relevant service whose scripts all date from perl4-only days and
> if I want to phase out /bin/perl as perl4 then I can do it all by
> myself. I think that fairly neatly ends that discussion - I'm already
> trying to juggle too many things at work.
Be careful next time you quote a job to make a minor modification; you
might end up rewriting the entire package!
Christopher F. Miller, Publisher firstname.lastname@example.org
MaineStreet Communications, Inc 208 Portland Road, Gray, ME 04039
Database publishing, e-commerce, office/internet integration, Debian linux.