All the Perl that's Practical to Extract and Report

RPMs

davorg on 2006-06-21T09:36:05

I've been dabbling with building RPMs from CPAN modules. Mostly they are modules I've written but I've also packaged a few dependencies that they have.

The RPMs are on my web site. I built them using Fedora Core 5, but in case that doesn't work for some people I've also made the source RPMs and the spec files available.

I'm interested in any comments you have about them. If it's successful then I might start a real yum repository.

RPM?

grantm on 2006-06-21T10:45:48

Have you not discovered Debian yet? :-)

Re:RPM?

davorg on 2006-06-21T10:58:36

I'm not going to get into distro flamewars. I've been using Red Hat based distributions since something like Red Hat 4.2 and I can't see any good reason for changing now. I'm aware that many people dislike Red Hat for various reasons, but I'm very happy with it.

If you want to repackage them for apt then feel free. I won't be doing it.

And besides, aren't all the Debian users moving to Ubuntu these days :-)

Re:RPM?

rafael on 2006-06-21T11:08:56

Well, I looked at the recent dpkg2 spec, and it seems that they finally are going to integrate quite a number of features that were present in rpm for years...

(Also, Debian lacks a good depsolver... Ubuntu uses dpkg packages, but comes with smart, which is much better than apt.)

((Not endorsing rpm, that said. I know the rpm guts fairly well and I do know what kind of crappy bugs there are in it, and how much poor design decisions plagued it historically...))

ENDOFTROLL

cpan2rpm--

rafael on 2006-06-21T11:01:44

So you use cpan2rpm ? I hate it. The produced specfile is unmaintainable, notably because it computes the filelist on the fly. But I'm anal (and I'm paid to produce good rpms of perl modules.)

A few additionnal notes (I took the Template-Toolkit one) :

* you must not set buildarch unless it's noarch, because rpm will figure it out by itself, and that might be a 64 bit platform, or a sparc, etc.

* there are no BuildRequires, but a good tool would be able to generate them from the META.yml for example. (of course human tweaking would always be needed.) That makes the rpm difficult to rebuild by automated processes (or even by humans). (rpm is able to figure out some of the requires by itself.)

Re:cpan2rpm--

davorg on 2006-06-21T11:15:04

So you use cpan2rpm ?

Yeah. It was quick and easy (and already installed).

I'm happy to look at other alternatives tho'. I keep meaning to look at Ovid but I love to hear other suggestions.

And thanks for the other suggestions. I'm really new to this and the current RPMs are provided very much on a "this works for me" basis - but I'll be working to raise the quality over the next few weeks.

Re:cpan2rpm--

rafael on 2006-06-21T16:12:20

Another suggestion would be to write a CPANPLUS backend for that.

Also, you might find this interesting :

http://qa.mandriva.com/twiki/bin/view/Main/PerlPolicy
http://gsd.di.uminho.pt/jpo/perl/specfiles/

The 1st link is the policy to make perl rpms for Mandriva. We don't have exactly the same policy than FC, and we have a more recent rpm, with a perl dependency generator that has been patched a bit -- but the general rules should apply to FC too. I think the 2nd link is more or less official for FC.

Re:cpan2rpm--

iburrell on 2006-06-21T16:51:44

cpanspec, http://cpanspec.sourceforge.net/, is pretty good and produces more maintainable and standard specs. It is used for many of the perl modules in Fedora Extras. I have been using it for local packages and it works on almost every Perl modules.