[Melbourne-pm] caching CPAN dist files
mathew.blair.robertson at gmail.com
Mon Apr 25 06:49:09 PDT 2011
> >> Perl has native versioning support and you can use the Makefile.PL
> >> (Build.PL, META.yml, etc) to get your dependencies checked for you,
> >> without having to make OS/brand specific install scripts. [ Since this
> >> is Perl, neither "dpkg" or "objdump", etc. are applicable **]
> >> ** I'm not sure why you mentioned those... is there a specific example
> >> where the standard Perl packaging tools dont cover some use cases?
> > sure, you have built a package depending on a os library such as
> > libmysqlclient.so, and you would like the native operating system to take
> > care of security fixes etc, but you want to signal to the os that your
> > package depends on those libraries and therefore do not allow a user to
> > uninstall the library (in this case libmysqlclient.so) OR upgrade it to a
> > incompatible version.
> In my case, there is a hand-built list of all those dependencies in
> the Debian package (for things like postgresql-client, mysql-client,
> libssl, libgd, libjpeg, libpng, etc etc).
None of these make much sense with depending on the OS-specific versions...
you should instead be relying on the equivalent Perl/CPAN module, ie:
DBD::mysql, DBD::Pg, GD::Simple, etc.
There might be some merit in using the package manager to manage
dependencies for a core library that needs wrapping ** but a given Perl
application should only need to depend on its required Perl modules.
** Even in this case, you dont need to create OS/Vendor specific packages,
cf Perl integration with Gentoo where dependencies are tracked across the
In fact the example of security updates, is exactly why you dont create your
own OS-specific package, and instead use the built-in support for
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Melbourne-pm