Bug #64378 for DhMakePerl: DhMakePerl needs Parse::DebianChangelog, but it isn't on CPAN

Sat Jan 01 08:23:20 2011 apeiron [...] cpan.org - Ticket created

Subject:

DhMakePerl needs Parse::DebianChangelog, but it isn't on CPAN

I'm trying to install DhMakePerl from CPAN. All goes well until it hits Parse::DebianChangelog. This distribution isn't on CPAN, so the install fails. All that should need doing is CPANing this module. Thanks!

Sun Jan 02 12:42:26 2011 jeremiah [...] cpan.org - Correspondence added 10 min

On Sat Jan 01 08:23:20 2011, APEIRON wrote: Show quoted text

> I'm trying to install DhMakePerl from CPAN. All goes well until it hits > Parse::DebianChangelog. This distribution isn't on CPAN, so the install > fails. All that should need doing is CPANing this module. Thanks!

Hi Apeiron, DhMakePerl is really on CPAN as a service to those who want to read its source code and to re-use code but don't have a Debian system at hand. It really is not designed to be installed from CPAN. The best way to install it is on a Debian-based system using this command; $ apt-get install dh-make-perl But, if you really can't do that, perhaps I can add whatever is missing on CPAN. This is less than ideal because if you are on a Debian system, then you're dependencies will be resolved to the application level by installing through the APT system. With CPAN, you will only get perl dependencies which is suboptimal. dh-make-perl is really a tool for creating policy compliant .deb packages so supporting it outside of a Debian system might not be that useful, but if it is just a matter of a module or two, perhaps I can sort that out.

Sun Jan 02 12:42:27 2011 The RT System itself - Status changed from 'new' to 'open'

Sun Jan 02 12:42:27 2011 jeremiah [...] cpan.org - Given to jeremiah

Sun Jan 02 21:48:34 2011 JAWNSY [...] cpan.org - Correspondence added

Jeremiah, et. al.: I understand that having a working dh-make-perl installable via CPAN is neither a goal of the Debian Perl Group, nor yourself or Damyan Ivanov, the primary hacker currently working on it. That being said, given that dh-make-perl is a Pure Perl package, I don't see why its constituent parts should not be at least somewhat useful on CPAN. I discussed this briefly with David Bremner in #debian-perl today, and for me it comes down to this: Users on non-Debian systems may sometimes want to use dh-make-perl. You can generate packages this way (though not build them without debuild/dpkg-buildpackage, etc.) and more importantly you can use the same code we use for other purposes, e.g. try to probe license files the same way we do, perhaps as a sort of comparison between our detection algorithm vs those someone else implements. It also allows for some code to be reused sometimes; even if you're not on a Debian OS, it may be useful to parse Debian-style changelogs. Anyway, I don't mind if this bug is assigned to me (in case you just don't care about the request) -- though me finding the time and inclination to work on this may take awhile too :-) Cheers, Jonathan

Mon Jan 03 05:20:28 2011 jeremiah [...] cpan.org - Correspondence added 10 min

On Sun Jan 02 21:48:34 2011, JAWNSY wrote: Show quoted text

> > That being said, given that dh-make-perl is a Pure Perl package, I don't > see why its constituent parts should not be at least somewhat useful on > CPAN.

Perhaps it should be completely on CPAN. This reverses the usual process where CPAN is upstream to Debian, now Debian will be upstream to CPAN, but that should not be too hard to manage. The real question is to determine if the work is worthwhile; will there be enough use of the packages to maintain dh-make-perl on CPAN? Show quoted text

> Users on non-Debian systems may sometimes want to use dh-make-perl. You > can generate packages this way (though not build them without > debuild/dpkg-buildpackage, etc.) and more importantly you can use the > same code we use for other purposes, e.g. try to probe license files the > same way we do, perhaps as a sort of comparison between our detection > algorithm vs those someone else implements.

Is this actually done by anyone? Is there a real world usecase? Show quoted text

> It also allows for some code to be reused sometimes; even if you're not > on a Debian OS, it may be useful to parse Debian-style changelogs.

This is definitely a worthwhile goal, and a lot of the packages that you guys have worked on would be useful in a CPAN context because people might as you see want to parse debs and supporting files without moving to a Debian system. Show quoted text

> Anyway, I don't mind if this bug is assigned to me (in case you just > don't care about the request) -- though me finding the time and > inclination to work on this may take awhile too :-)

Shall we try and set some targets and a timeline / roadmap for us to get this done? If you and I do this together, it is more likely that we can get the packages in good shape on CPAN. How does that sound? Show quoted text

> Jonathan

Thanks Jawnsy! Jeremiah

Mon Jan 03 06:26:28 2011 dam [...] cpan.org - Cc JAWNSY added

Mon Jan 03 06:27:04 2011 dam [...] cpan.org - Correspondence added

On Mon, 3 Jan 2011 04:48:34 +0200, JAWNSY wrote: Show quoted text

> [...] given that dh-make-perl is a Pure Perl package, I don't > see why its constituent parts should not be at least somewhat useful on > CPAN.

A prove to the usefullness outside of Debian would be nice and maybe even motivating. Show quoted text

> I discussed this briefly with David Bremner in #debian-perl today, and > for me it comes down to this: > > Users on non-Debian systems may sometimes want to use dh-make-perl. You > can generate packages this way (though not build them without > debuild/dpkg-buildpackage, etc.)

The module->package dependency matching is one of the greatest features of dh-make-perl. Take this away, and you can have a debian/ directory populated, probably even with other useful data (e.g. copyright summary, description ets). Without dependencies, these are of little use. Besides, what is the purpose of creating the debian/ directory if building a (binary/source) package is never to be done? Show quoted text

> and more importantly you can use the > same code we use for other purposes, e.g. try to probe license files the > same way we do, perhaps as a sort of comparison between our detection > algorithm vs those someone else implements.

I am not sure the the module is suited for such use. Show quoted text

> It also allows for some code to be reused sometimes; even if you're not > on a Debian OS, it may be useful to parse Debian-style changelogs.

Even if you upload Parse::DebianChangelog to CPAN, it is not the only dependency that is needed. There is at least AptPkg too. It is not pure Perl and requires the libapt-pkg library present in order to build and run :/ Show quoted text

> Anyway, I don't mind if this bug is assigned to me

Sure. I have added you as a CC, feel free to take it if you wish.

Wed Feb 09 20:20:53 2011 mutant.nz [...] gmail.com - Correspondence added

From:

mutant.nz [...] gmail.com

Just wanted to add a vote for the usefulness of DhMakePerl being installable via CPAN. My use case is that I have an old version of dh-make-perl, but I want to use some of the new features (like --recursive). I can build a new .deb manually, or hope something is on backports, or I could (in theory) run: dh-make-perl --build --install --cpan DhMakePerl Then I'd have the latest version of dh-make-perl installed as a .deb, which is one of the advantages of the tool in the first place. There may be an easier way to do this, but this seemed like the obvious step to me.

Thu Feb 10 05:04:46 2011 jeremiah [...] cpan.org - Correspondence added

On Wed Feb 09 20:20:53 2011, Mutant wrote: Show quoted text

> Just wanted to add a vote for the usefulness of DhMakePerl being > installable via CPAN. > > My use case is that I have an old version of dh-make-perl, but I want to > use some of the new features (like --recursive). I can build a new .deb > manually, or hope something is on backports, or I could (in theory) run: > > dh-make-perl --build --install --cpan DhMakePerl > > Then I'd have the latest version of dh-make-perl installed as a .deb, > which is one of the advantages of the tool in the first place.

But note that you won't get all the advantages of a deb that comes from debian's repos. You won't be assured that lintian and puiparts have been run on the deb, and if someone finds a security or other bug, you'll have to rebuild your deb. Show quoted text

> There may be an easier way to do this, but this seemed like the obvious > step to me.

I agree, this is easy. But I think that the extra step of building dh-make-perl from git to get the latest and greatest is a better way to go. This allows you to stay very close to HEAD to get all the features, and if something breaks you can report it, thereby improving the tool for everyone. Yes, it might mean you have to dh-make-perls, and that you don't install the new dh-make-perl as a deb and therefor it isn't in the APT database, but I still think this is better than being stuck halfway between both these solutions which building your own deb puts you in. I'm picking nits here and hope I don't appear as too negative, I just want everyone to know abou the potential consequences of building and relying on locally built debs.

Sat Aug 20 11:24:24 2011 dam [...] cpan.org - Status changed from 'open' to 'stalled'

Sat Aug 20 11:24:24 2011 dam [...] cpan.org - Severity Critical changed to Important