Re: YAPC North America talk on dh-make-perl vs. CPANPLUS
On Wed, Jun 10, 2009 at 5:48 PM, Jeremiah
> On Jun 10, 2009, at 16:36, Guy Hulbert wrote:
>> On Wed, 2009-10-06 at 10:21 -0400, Guy Hulbert wrote:
>>> It might be useful to review: CPANPLUS::Dist::Deb
>>> to see if it checks under /usr before installing things in /usr/local.
>> Hmmm.... they're recommending:
>> deb http://debian.pkgs.cpan.org/debian unstable main
>> Let's see:
>> zless Packages.gz
>> Maintainer: email@example.com
>> Not a particularly useful email address ...
>> Let's look at a package: cpan-libfile-path-perl_2.04-1_all.deb
>> wget ...
>> ar x cpan-libfile-path-perl_2.04-1_all.deb
>> tar ztf data.tar.gz
>> So it's under /usr/local but the docs are under /usr:
>> Hmm... I'd suggest that they use /usr/local/share/doc to avoid confusion
>> but I don't suppose debian policy has much to say here.
> I think the key is in fact the debian policy. If you want a quick n dirty
> package, you can use the CPANPLUS tool I suppose, but if you want DSFG safe,
> perl policy compliant, license and copyright checked package, then you want
> a deb made by debian perl. (Or make it yourself. :)
> Perhaps code can be written to adhere to the perl and debian policies, but I
> suspect that will never be done since that is a moving target, or it should
> be. The policy should be evolving as best practices are defined.
> Maybe what is needed is the modularization of dh-make-perl in to perl
> modules and released on CPAN?
This is a very valid point. We need to work on exposing the
dh-make-perl internals so that other things like cpan2dist can use it,
while not having to constantly update their stuff to keep in sync with
policy. I'd also like to push for dh-make-perl to be release normally
via CPAN. Currently though I'm scared of the codebase, as it's fairly
messy stuff. damyan is brave :-)
Indeed though, a good long term goal is figuring out a good pattern
for exposing the API, so we can upload them as normal modules via
CPAN, and so they can be used directly by cpan2dist instead of having
to roll their own stuff.
I think that has the best outcome for everyone, and the DhMakePerl.pm
is a good first step in that direction.
> To UNSUBSCRIBE, email to debian-perl-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact