Maybe it's the word "database" that has spooked you

No, it was the image in my mind of an install routine doing a search on a big disk partition and a clueless admin sitting there wondering what on earth this install script is doing.

I've brought up all those (often farfetched) examples not as specific grievances you should protect against, but just to show there are reasons why (some?) people want an install to be just an install. This is independent of the actual module. If I installed a library or module that could cache sound files I also wouldn't like the install routine to automatically search the disk for sound files and creating the cache. An application program maybe, but a module/library, definitely not. Or a module that creates rainbow tables for AES should not start to build the rainbow tables as part of the install, obviously ;-)

Naturally, if you need a database for testing, that is different. But in that case the problem is that you have to provide the test data yourself as you can't expect any fitting test data on the machine. So if you have to provide the test data anyway, why make a time wasting and installation dependant search for additional data if you already got the test data?

To make an example: I remember that there was a perl module for connecting over the network. For the testing it actually tried to access the internet. Which was bad, because it didn't test only the module. It also tested the whole network, the firewall and the internet connection, extrinsic features to the module. An installation to fail because of external circumstances like a turned off router sends a wrong signal. If your testing depends on data you find on the machine you get into the same danger of testing something external to your module. For example corrupted html files on the web server should not lead to test failures for your module

In reply to Re^7: RFC: Apache2::CloseKeepAlive by jethro
in thread RFC: Apache2::CloseKeepAlive by cmac

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.