[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: advice on package containing both .pm & .pl



Penny Leach wrote:
> I'm packaging buffycli, which is a text mode alternative to buffy. It
> is comprised of one perl module Buffy::CLI, and one script.  It depends
> on libbuffy-perl which is built from swig (and somewhat a black box as
> far as I'm concerned)
>
> buffycli is not on cpan and I am the upstream author.

Out of curiosity: why is Buffy::CLI not on CPAN?  Publishing to CPAN is 
pretty easy.

> I've changed my mind 6 times about the best way to package this.  The
> perl policy is helpful about how to package perl modules, and how to
> package scripts, but I can't see clearly what to do if there are both.
>
> As I see it, there are two options:
>
> 1. create two packages, one libbuffy-cli-perl which just contains the
> perl module and I can build pretty easily with dh-make-perl, and the
> other package containing the script itself, which depends on the first
> package
>
> 2. build one package and don't do the pm the normal way, but just
> install the script into /usr/bin, and the module into /usr/share/perl5/
>
> 1. seems like overkill but technically more correct and in line with
> policy?
> 2. seems much less complicated but potentially not correct?
>
> if there's an obvious solution I'm missing, or an example package(s)
> that does what I want that I can copy that would be aces.

You aren't missing any solution that is better than the two you brought up 
yourself.

I think which one of the two is best in your case depends on whether 
Buffy::CLI is currently, or will be in the foreseeable future, used by 
any programs or Perl modules _besides_ the one script you mentioned?  
Given that Buffy::CLI is not on CPAN, that's probably not the case (but 
what do I know?).

If your module is used by pretty much only your script, then I'd just 
create a single package with the script in /usr/bin and the module 
in /usr/share/${pkgname}/lib/Buffy/CLI.pm, and have your script say

  use lib '/usr/share/${pkgname}';

to enable the module to be loaded from the non-standard include path.
That's what I did in my courier-filter-perl source package, which ships 
both some programs and library modules used exclusively by those 
programs.  For the latest release of the package, look here:
http://mentors.debian.net/debian/pool/main/c/courier-filter-perl/

If your module will potentially be used by other programs or modules, then 
I'd create two binary packages from a common source package, one for your 
module and one for your program, with the latter depending on the former.  
That's what I did in my mail-spf-perl source package, which is in the 
Debian archive proper and current.

Julian.

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: