Module::Build is fine, a good idea is to use Module::Starter (and Module::Starter::Smart) to create the skeleton of a CPAN-ready module automatically

I must confess I don't know what you mean with GP Perl. It can't be Perl Genetic Programming System, right?

I don't think a module installation should ask questions. Questions should be asked by the program that uses a module.

SoPW would certainly have gotten this post more notice! I was influenced by the stuff in the header of Meditations about "sounding board" and "RFC", and I'm too lazy to try to move it now.

I use GP as a standard abbreviation for general purpose. The general purpose Perl library is typically headed at /usr/local/lib/perl5 on unix systems.

People on the mod_perl mailing list have talked me into letting the module and accompanying database-building script go into the GP perl library and standard 'script' or 'bin' location, respectively.

The install process will (quietly) run said accompanying script. It builds a database that maps .htm(l) filenames to the number of .jpg files called out by each. Module::Build plus the CPAN config have good features for various kinds of files, but they don't include a place for data files.

The inclusion of Apache::Test will probably let the Build process know the location of Apache. Probably it could be set up to make (if necessary) a 'var' subdirectory in the Apache directory, and put the database there. Is that better than asking the user where to put it?

That seems like a good thing to do, since the info in the DB is based on the sibling 'htdocs' directory. Actually putting the DB in htdocs doesn't appeal to me.

Thanks for your interest,
cmac

Maybe I'm too conservative here, but as sysadmin I don't like libraries/modules that do more than install when I tell them to install.

For example, I might not have apache and/or the jpegs and html files installed when I install your module.
I might not want all htmls and jpegs included in your database.
This could be DOM0 of a virtual setup and only the clients should have those databases.
I might have more than one apache installed, only one should get the treatment.
Maybe I just want to look at the module to evaluate it for a different machine.
Maybe I have a non-standard installation that will let your script do something bad if not adapted.
Maybe I have a few terabytes of jpegs and html so that your database would overflow the /var space.
The machine might have some security setup where the unexpected creation of files in specific directories leads to emergency shutdown of the machine.
The sysadmin might have very different ideas about where your database should be put.
The installation might have to be redone a few times (maybe because it is part of a bigger installation script that doesn't work correctly) and it wastes 20 minutes every time.
Or there were some changes necessary in the database and every reinstall of a new version of your module will overwrite those changes
Maybe there are hundreds of machines all of which get the same identical library installation, but only one of the machines will be a web server. And all have access to a big html-data directory through (traffic-heavy) NFS.

Calling your init script should be done explicitly by anyone using your module. He should know what to expect, should know what your init script does before he calls it. You should put a text something like 'Call the script with parameters a and b to initialize the database before first use. This will do the following:...' into the usage description of the pod documentation.

All this IMHO