I disagree. I think auto updating of data is sometimes important, and Sysadmins often have more important things to worry about, especially if they are remote from the users of the perl module or if updates are frequent.

I have been a perl user in large bureaucratic corporations before, and trying to get a perl module installed system wide (so that any of my users could run a script that used it without further configuration) required months of lobbying. If I had asked for a cron job for auto updates as well then that would have been impossible. Needless to say we where stuck on perl 5.6 for years.

My view is that if updates are infrequent, (eg yearly), then just include the file in the distribution and release a new version when it needs updating. If updates are predicable in advance then you can make the module complain if it is to old.

If the updates are more frequent (eg weekly) than that then provide an update mechanism that can be used both by the sysadmin if they care, or by an unprivileged end user within the script that uses the module. I would have something like:

use Foo;
use Foo::Updater;

Foo::Updater->new->update()
# Rest of script here
[download]

That call to update would compare the timestamp of a local cache with the latest version on your server, and pull the update if required. If the user is non privileged then the update gets put in their home directory. If the user is root then it goes to a central system wide location that all users can read. That way if the sysadmin cares, (Or if they notice the disc space and bandwidth consumption of hundreds of identical copies of the update data) they can setup a cron job to pull the updates, but if they don't care then users get the data anyway without their intervention.