After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 342638 - support for building CPAN modules
support for building CPAN modules
Product: jhbuild
Classification: Infrastructure
Component: general
Other Linux
: Normal normal
: ---
Assigned To: James Henstridge
Jhbuild QA
Depends on:
Blocks: 342435
Reported: 2006-05-22 23:03 UTC by Frederic Peters
Modified: 2006-06-19 05:15 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16

Jhbuild CPAN support (8.86 KB, patch)
2006-05-22 23:04 UTC, Frederic Peters
none Details | Review
<perl> support (6.20 KB, patch)
2006-05-23 20:18 UTC, Frederic Peters
none Details | Review

Description Frederic Peters 2006-05-22 23:03:01 UTC
system-tools-backends now depends upon Net::DBus; this requires jhbuild to support CPAN modules.

The attached patch adds preliminary support, since I am no Perl user I'm not that sure everything is done according to the rules, I looked into dh-make-perl to get an idea of common steps.

Ideally it would have been great just to have to add Net::DBus to moduleset and have Perl CPAN support do most of the work but I couldn't get it to isolate steps; I kept a note about this ideal support but added a <source> tag identical to the one in <tarball>; see:

  <cpan id="perl-net-dbus">
    <module name="Net::DBus" /> <!-- XXX: this would be ideal -->
    <source href=""
            size="78309" md5sum="0d778004934e3597c8e841d7197c21cb"/>
      <dep package="dbus"/>

I can commit this whenever I get my account and you are happy with the patch.
Comment 1 Frederic Peters 2006-05-22 23:04:03 UTC
Created attachment 66025 [details] [review]
Jhbuild CPAN support
Comment 2 James Henstridge 2006-05-23 14:52:33 UTC
Two immediate issues:

(1) is CPAN the right name for this?  Would the Perl make infrastructure usually be described as "CPAN" when not using the CPAN shell to build stuff?

(2) rather than copying the Tarball module type, it would be better to copy the Autotools module type.  There is a tarball versioncontrol backend that will handle tarball builds, and this would also allow the module type to work with CVS, Subversion, Darcs and GIT with no additional coding.

The <module> sub-element seems superfluous.  In your patch the module_name doesn't seem to get used at all.  Is it actually needed?

If you base the module type on <autotools>, the XML for it might look something like this:

  <repository type="tarball" name="cpan" href="" />

  <cpan id="perl-net-dbus">
    <branch repo="cpan"
        module="authors/id/D/DA/DANBERR/Net-DBus-0.33.1.tar.gz" version="0.33.1"
        size="78309" md5sum="0d778004934e3597c8e841d7197c21cb"/>
      <dep package="dbus"/>

(this also lets people override the repository URL to pick a different CPAN mirror).
Comment 3 Frederic Peters 2006-05-23 14:57:36 UTC
CPAN was the right name at the start, when I thought I could use Perl CPAN module/command to get this working, module_name and the associated tag is a remnant of that era.

History pushed aside <perl> might be better than <cpan>; I'll work on a patch implementing your comments this evening.
Comment 4 Frederic Peters 2006-05-23 20:18:46 UTC
Created attachment 66084 [details] [review]
<perl> support

This implements Perl module support as outlined in your comment; also PerlModule class inherits from AutogenModule to avoid code duplication.
Comment 5 James Henstridge 2006-06-19 05:15:52 UTC
I've committed a modified version of your patch to bzr and merged to CVS.

Rather than trying to shoehorn PerlModule in as a subclass of AutogenModule, it is now a direct subclass of Package.  This simplifies things a bit.

I also updated the module to the new state skipping framework, which simplifies the logic a bit.