Distribution installer that defaults to Debian?

[Joel Roth]

On Sun, Dec 19, 2010 at 01:36:26PM -1000, Joel Roth wrote:
> Hi all,
> 
> I often find myself going through the same ritual
> when installing a new module, say Something::Great
> 
> Do I have it already?
> 
>     perl -MSomething::Great -e 1
> 
> Does Debian have it?
> 
>     apt-cache search libsomething-great-perl
> 
> If Debian has it, I install with apt-get, if not,
> I install with a CPAN client (these days cpanm)
> into a local::lib.
> 
> Is anyone aware of some tool that does this?  Otherwise I might
> write a simple script.

Hi all,

When David Golden announced a new version of the CPAN
client, I took the opportunity to ask about a hook to
use a native (i.e. Debian) installer for distributions
when available. He replied at some length, which I 
include with his permission below.

In summary he said:

* CPAN has not solved the issue of meeting
  dependencies on binary libraries -- the libfoo problem --
  which dpkg addresses

* he acknowledges there is a set of users who would prefer
  seamless use of OS-default perl and compatible
  modules/libraries, although power users tend to use perlbrew / local::lib 
  and bypass the default system perl.

* the codebase of the current CPAN client is not suited for
  adding plugins, which will require major refactoring effort.

* we may be better off attempting to do this with cpanminus
  or other more recent cpan client

* a first step would be to index perl distribution names to 
  Debian packages. (Debian::AptContents handles that for
  us.)

* He also mentioned appropriate forums to discuss the issue.

Regards,

Joel



--------- start included mail --------

Date: Tue, 15 Feb 2011 15:17:13 -0500
From: David Golden <dagolden at cpan.org>
Subject: Re: CPAN client support for mix of CPAN and OS-packaged Perl
        distributions

On Tue, Feb 15, 2011 at 2:36 PM, Joel Roth <joelz at pobox.com> wrote:
> Hi David,
>
> I just saw your announcement about improvements in CPAN.
> Thanks for that!
>
> Not sure if there is an appropriate mailing list or other
> better forum for this issue. If so, let me know.

Hi, Joel.  There are a couple forums for these kinds of discussions.
For mailing lists, there is cpan-workers at perl.org (email
cpan-workers-subscribe at perl.org to subscribe).  On IRC, the #toolchain
channel on irc.perl.org has most of the CPAN/CPANPLUS/cpanm and other
toolchain hackers, along with many distribution porters as well. E.g.
jawnsy for debian.

> I've had some discussions in the Debian Package Perl group,
> (which maintains Debian packages of over 1500 perl distributions)
> about options for working with a mix of CPAN-supplied
> and OS native-packaged perl distributions.

I subscribe to debian-perl, though I admit I rarely read all the messages.

> In general, the Debianized distributions install easier, are more
> thoroughly tested under Debian, and most users prefer them
> when they are available.

I hear that most power users within the Perl community find that the
Debian installed perl is woefully out of date and the latest trend
seems to be people using App::perlbrew to maintain their own perl and
install modules from CPAN.  That doesn't solve the binary library
dependency issues, but different audiences are optimizing for
different things.  It's worth keeping in mind depending on which
audience you're most interested in optimizing for.

That said, I support the idea of people having the option of
distribution native packages of Perl libraries and support the idea of
a more seamless experience for those who insist on using the default
system perl.

> (If there is an API for getting dependency information
> about CPAN modules, I'd like to know about it.)

In Perl 5.14, we expect to have both Module::Build and
ExtUtils::MakeMaker generating MYMETA.json files.  These follow the
CPAN Meta specification, but contain post-configuration dependencies,
with all conditional dependencies resolved.  See CPAN::Meta for the
interface and CPAN::Meta::Spec for the specification.  The MYMETA
approach was designed expressly for the purpose of providing a better
way for toolchain modules to communicate using an existing standard
supported by most of the toolchain.

Unfortunately, it's still limited to perl dependencies -- knowing that
some perl module requires libfoo is a still unresolved conundrum that
I'm sure every distribution packaging team deals with all the time.

> If agree it is worthwhile and the CPAN client can provide an
> interface, I'd be pleased to work with the Package Perl
> group to provide a Debian plugin.

My long term vision is to see the major CPAN clients eventually
transformed from monolithic tools to coordinated shells around a
collection of small tools  (akin to the Unix pipeline mentality).
That would make the kind of plugin system you describe much easier to
accomplish.  Unfortunately, at this point, there is too much spaghetti
code inside CPAN for me to want to tackle that kind of plugin system
until lots of other refactoring has been done -- which is a long term
project.

What would be beneficial -- if it doesn't already exist -- is the
equivalent of the "modules/02packages.details.txt" file on CPAN, but
that maps a given module name to a debian distribution name.  I don't
think this is always regular, as the recent discussions about
App::cpanminus have shown.

Assuming that the index existing existed -- possibly just as a web
service somewhere -- then it would be fairly easy for less
legacy-limited tools like cpanminus to resolve a dependency on debian
by checking that index and trying to install the debian package and
only then fall back to a CPAN installation, just as you envision.

That small piece -- just the index -- is the first step that would
enable some innovation along the lines you describe.  I would
encourage you to take it up on cpan-workers or #toolchain if you're
interested.  (I am 'xdg' on #toolchain, btw).

You should also see App::CPANIDX as an example of the kind of
web-accessible indexing that I'm talking about.  The metacpan.org team
might also be interested in incorporating this kind of index.

Regards,

David

----- end included mail ---

-- 
Joel Roth