[Melbourne-pm] caching CPAN dist files

Mathew Robertson mathew.blair.robertson at gmail.com
Wed Apr 20 15:14:02 PDT 2011


On 21 April 2011 06:48, David Dick <ddick at iinet.net.au> wrote:

> On 20/04/11 11:35, Mathew Robertson wrote:
>
>> Hi Toby,
>>
>> I am not familiar with how this would do the dependency checking
>> required -> how would building a package containing exactly the
>> installed files, differ from simply creating a tarball?  ie: it appears
>> this technique completely ignores the OS versioning problems...
>>
>
> well, technically since toby is creating a debian package, the difference
> is he has wrapped a tarball inside an arball :)
>
> But the practical difference is, creating any sort of native os package is
> the first step to calculating dependencies.  Once you have a debian package
> (or a rpm, or whatever), the next step is to examine your build directory
> for dependencies and list them in the package.
>
> For example, run 'file' on everything in the build directory, grep for
> 'shared object' or 'executable', run 'objdump -p' on that, discover the
> library names that aren't in the build directory and run 'dpkg -S' on those
> libraries.  That list (plus version numbers from 'dpkg -s' if you want) goes
> straight into the control file in the debian package.
>
>
I do already understand the requirement for determining dependencies, and so
my question.... If you stick every package into an OS specific target (in
this example, /usr/local/$NAME/perl) using the packages' installer, you end
up with a list of files that are dependent on that OS... and so "how is this
different from a tarball?".

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 **]

Toby's answer was perfectly acceptable -> the build process creates an
OS-versioned target, at the expense of being cross-platform like the actual
modules being used.

Mathew

** I'm not sure why you mentioned those... is there a specific example where
the standard Perl packaging tools dont cover some use cases?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/melbourne-pm/attachments/20110421/7b6e8234/attachment.html>


More information about the Melbourne-pm mailing list