On Sat, 2005-04-23 at 03:42 -0400, Chip Turner wrote: > Warren Togami <wtogami@xxxxxxxxxx> writes: > > > Ville Skytt�rote: > >> 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? I didn't get around to replying to Ville's email ( https://www.redhat.com/archives/fedora-perl-devel-list/2005- April/msg00006.html ), but I agree with him and Chip. I don't think we should just blindly package everything on CPAN, but we should make it as easy as possible to package and review the stuff that we want. 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. * Have cpanflute2 query CPAN to automatically fill in %version, %URL, %Source0 * Have cpanflute2 look for common doc files and add them to %docs 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> 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. Cheers -- Dennis
