Ville Skyttä wrote:

On Mon, 2005-04-18 at 15:36 +1000, Rob Kearey wrote:

...

CPAN+ can build debian packages with CPANPLUS::Dist. Would it be worthwhile creating an RPM target?

Would it offer something that cpan2rpm or RPM-Specfile already don't?

https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list Chip has expressed that he wants to fix cpanflute2 (shipped in Core) to do exactly what we want. Let's get him on this list. Hey Chip this is the Fedora Project perl team's devel list. I aim to keep list traffic here low noise through strict moderation and zero tolerance for bullshit.

While cpanflute2 writing specs closer to the Fedora Project perl spec template would help us, it will never be a fully automated process. Each package needs to be analyzed to disable part or whole of "make test" because it is inappropriate to run network tests in the build system. Other packages need to be told the location of other non-perl software and stuff.

Warren Togami wtogami@redhat.com

On Mon, 2005-04-18 at 12:03 -0400, Dennis Gregorovic wrote:

Even if we can't fully automate the process, the more we can automate, the better. My question is: which of the available tools[1] should we focus on? If Chip is looking to work on cpanflute2, that would be great.

Could you elaborate on what exactly what process are you talking about? Automagically packaging as many CPAN modules as possible? There's already http://rpmpan.sourceforge.net/ which IIRC uses cpanflute2, but I have no real experience with it (RPMPan). They probably have quite a bit of experience in doing this.

cpanflute2 could be tweaked more towards suitability for Fedora/RHEL purposes, but I'm afraid doing so could make it less useful for other distros. That's Chip's call, of course.

I don't personally believe in blindly autopackaging stuff in the first place (not only for Perl modules), but maybe you're not talking about this.

A CPANPLUS::Dist::RPM module would be useful for installing Perl modules as RPMs created on-the-fly, but that's not quite what we need in Fedora Extras.

yum install fedora-rpmdevtools emacs perl-Foo.spec # or xemacs # (X)Emacs containing a pre-filled Perl spec template comes up, just # fill in the blanks and save it. spectool -g -R perl-Foo.spec rpmbuild -ba perl-Foo.spec

The above is enough for me for now... if for some weird reason someone uses vi :), maybe similar stuff can be hacked up for it too.

Somewhat OT: stuff I haven't seen mentioned elsewhere that could be useful for automatically finding (Build)Dependencies, maybe someone has used or evaluated some of these? rpmbuild obviously already has internal magic for the install time deps, but tools like cpanflute2 could use something like these for pre-filling build deps. http://search.cpan.org/dist/Module-Depends/ http://search.cpan.org/dist/Module-Dependency/ http://search.cpan.org/dist/Module-ExtractUse/ http://search.cpan.org/dist/Module-Info/ http://search.cpan.org/dist/Module-MakefilePL-Parse/ http://search.cpan.org/dist/Module-ScanDeps/

On Mon, 2005-04-18 at 19:23, Rob Kearey wrote:

Ville Skyttä wrote:

...

I don't personally believe in blindly autopackaging stuff in the first place (not only for Perl modules), but maybe you're not talking about this.

CPAN being what it is, I can't see much alternative.

I'm sorry, I didn't understand the context here -

You don't see any alternative BUT to autopackage CPAN, or you don't see any alternative except NOT autopackaging CPAN?

Warren Togami wtogami@redhat.com writes:

Ville Skyttä wrote:

...

On Mon, 2005-04-18 at 15:36 +1000, Rob Kearey wrote:

...

CPAN+ can build debian packages with CPANPLUS::Dist. Would it be worthwhile creating an RPM target?

Would it offer something that cpan2rpm or RPM-Specfile already don't?

https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list Chip has expressed that he wants to fix cpanflute2 (shipped in Core) to do exactly what we want. Let's get him on this list. Hey Chip this is the Fedora Project perl team's devel list. I aim to keep list traffic here low noise through strict moderation and zero tolerance for bullshit.

While cpanflute2 writing specs closer to the Fedora Project perl spec template would help us, it will never be a fully automated process. Each package needs to be analyzed to disable part or whole of "make test" because it is inappropriate to run network tests in the build system. Other packages need to be told the location of other non-perl software and stuff.

Hi guys!

Sorry for the late response. Been a busy couple weeks (new job, moved across country, all those convenient excuses).

I am indeed happy to improve RPM-Specfile in whatever ways we can brainstorm and in whatever ways will help Fedora. Right now, the source is embedded in the middle of my own personal subversion repo, but I can split it out into something more public if people are interested.

I've read over the archives (still waiting for moderator approval to join), but as far as RPM-Specfile's general use... well, it's always been intended to work on RHL/RHEL/Fedora. I'm not aware of anyone who really used it on other distros. That's not to say I would blindly make it forever incompatible with other distros, but the priority has always been supporting RHEL/Fedora and so I'm comfortable keeping along that same path.

I agree also that just packaging every tarball is a bad idea... there's a lot of bad stuff on CPAN. But, ideally, it should be as simple as saying 'make an rpm of Fritzy-Blip' and it happens, so that we can rapidly package as much interesting stuff as possible.

So... what do we need cpanflute2 to do better?

Chip

Dennis Gregorovic dgregor@redhat.com writes:

Here are some ideas off the top of my head:

• Have cpanflute2 discover if the package is noarch or not, and set up the %build, %install, and %files sections accordingly.

If you have perl-Archive-Tar and perl-Compress-Zlib (or is it perl-IO-Zlib these days?) installed, it will already do this. It is a lousy heuristic (walk the tarball, see if ther are any .xs, .c, or .h files), but in practice it works pretty much 100%.

• Have cpanflute2 query CPAN to automatically fill in %version, %URL, %Source0

It should automatically fill in version, but cpanflute2 operates from the tarball, so it bases it on the version in the tarball's filename.

• Have cpanflute2 look for common doc files and add them to %docs

It already does this too. It relies on the 'make install' of the perl module to copy them, but it does flag a variety of commonly named files as %doc.

The workflow I picture is: $ cpanflute2 Test::AutoBuild ... looking up Test::AutoBuild ... downloading Test::AutoBuild-1.0.3 ... examining Test-AutoBuild-1.0.3.tar.gz ... writing perl-Test-AutoBuild.spec $ emacs perl-Test-AutoBuild.spec

<visual inspection. make any needed changes>

Ah, this is the rub. Right now, cpanflute2 operates on an already-provided tarball. You have to download it on your own.

Downloading from CPAN is, unfortunately, not an entirely clean operation. At least, it wasn't last time I looked. You need to worry about mirrors, and about finding a module by a given name, etc. Unfortunately, as of now, there isn't a very clean way to do that from what I understand. cpan2rpm jumps through several different hoops to download packages; I'm just not sure that it is the right thing to do inside of cpanflute2. It is the area they can definitely say they are better, but I'm not sure I like the price of meeting them there.

This is similar to Ville's process. I'm just wondering how many of the 'blanks' we can fill in automatically.

Apologies in advance if any of these features are already implemented.

No problem! Not like there is a page listing cpanflute2's features anyway :)

Chip

Kenneth Porter shiva@sewingwitch.com writes:

--On Tuesday, April 26, 2005 12:38 AM -0400 Chip Turner cturner@pattern.net wrote:

...

It should automatically fill in version, but cpanflute2 operates from the tarball, so it bases it on the version in the tarball's filename.

I'd definitely like to see cpanflute2 be a bit smarter about package/directory/tarball names. I'd like to see it peek inside the tarball directory structure to cook up the right %setup directive, allowing the tarball name to have no relation to the BUILD directory name.

Until recently I needed a patched version of MIME::tools that came in a file named MIME-tools-5.411a-RP-Patched-3.tar.gz which confused cpanflute2 badly. (The package has since been adopted by the MIMEDefang maintainer and has a more reasonable tarball filename.)

Your wish is my command. cpanflute2 will now inspect the tarball (assuming it can; gotta have perl-Archive-Tar and perl-IO-Zlib). If the first directory of every file in the tarball is consistent, then that is what will be passed to %setup (with the version replaced with %{version}, if possible). It falls back to the old behavior if it cannot determine a common prefix. Will this suffice for your needs?

...

Downloading from CPAN is, unfortunately, not an entirely clean operation.

What does CPAN.pm do to accomplish this?

Lots. Remember the first time you installed CPAN.pm and it found mirrors, used about six differnt modules to download from, prompted you for lots of info, etc? It left its droppings in ~/.cpan of all the decisions it made. In essence, basically you have to download an index of cpan and inspect it to find what the latest version of a module is, and then find the path to it. There seems to be no API to do this cleanly against, say, search.cpan.org. I've submitted a nebulous feature request to s.c.o, but no telling how/when/if that will work.

I recently needed to install CGI::Builder and after a brief attempt at using cpanflute2, I gave up and went to /usr/bin/cpan to install the associated Bundle module. It would be great if some kind RPM mechanism was available to do the equivalent.

http://search.cpan.org/~domizio/CGI-Builder-1.26+/lib/Bundle/CGI/Builder/Complete.pm

Was what was blocking you the manpage thing and the %setup directory, or something else?

Chip

On 4/28/05, Chip Turner cturner@pattern.net wrote:

...

...

Downloading from CPAN is, unfortunately, not an entirely clean operation.

What does CPAN.pm do to accomplish this?

Lots. Remember the first time you installed CPAN.pm and it found mirrors, used about six differnt modules to download from, prompted you for lots of info, etc? It left its droppings in ~/.cpan of all the decisions it made. In essence, basically you have to download an index of cpan and inspect it to find what the latest version of a module is, and then find the path to it. There seems to be no API to do this cleanly against, say, search.cpan.org. I've submitted a nebulous feature request to s.c.o, but no telling how/when/if that will work.

You can use CPAN to do this, here is some code I wrote to try and make cpan2rpm recursively get modules from cpan, rpmbuild and the install the rpm. It works fine on modules but did not work for distributions, I believe this failure may be due to me having a mixed threaded/non-threaded perl install <shiver>. Hopefully this may help you.

This assumes you have CPAN setup, I ran the cpan shell and set it up, no modules where installed using CPAN though. Also requires a few CPAN modules, like CPAN::Dependency.

--snip cpan2rpm code ---

my $name = $info->{dist}; my $obj;

if($CPAN::META->exists('CPAN::Module',$name)){ cpan_get_deps($info, $name); } elsif($obj = CPAN::Shell->expand("Distribution", "/$name/")){ die("Distributions not handled yet: $name\n"); # may work on proper perl installs } elsif($obj = CPAN::Shell->expand("Bundle", "/$name/")){ die("Bundles not handled yet: $name\n"); } else{ die("Unknow type for $name\n"); }

--end snip cpan2rpm code ---

# Get the dependencies for a module sub cpan_get_deps { my $info = shift; my $name = shift || die("cpan_get_mod needs a name!\n");

use CPAN::Dependency;

my $cpandeps = CPAN::Dependency->new(process => $name); $cpandeps->run; # this may take some time.. foreach my $modl ($cpandeps->deps_by_dists()) { foreach my $parent (keys(%$modl)){ foreach my $name (keys(%{$modl->{$parent}->{prereqs}})) { $name =~ s/-/::/g; $name =~ s/.pm//; eval("use $name");

if($@){ cpan_get_mod($info, $name); } } } } }

# Fetch a module sub cpan_get_mod { my $info = shift; my $name = shift || die("cpan_get_mod needs a name!\n");

my $module = CPAN::Shell->expand("Module", $name) || die("Could not handle $name\n"); my $version = $module->cpan_version; $module->get; my $auth = CPAN::Shell->expand('Author', $module->userid); my $author = $auth->fullname;

my @args=("cpan2rpm");

if($info{install}){ push(@args, "-i"); } @args = (@args, "--author '$author'", "--version '$version'", $CPAN::Config->{cpan_home} . '/sources/authors/id/' . $module->cpan_file);

my $cmd = join(" ", @args); if(system($cmd) != 0){die("Could not process module: $name");} chdir $info->{evaldir} || die "get_meta(): $!";

return(0); }

Jeff Fearn