CPAN RPM archive?

Ville Skyttä ville.skytta at iki.fi
Mon Dec 1 19:06:10 UTC 2003


[fedora-devel-list back to Cc and quoted in full, I don't know if the
copy was accidentally omitted]

On Mon, 2003-12-01 at 10:50, Stan Bubrouski wrote:
> On Sun, 2003-11-30 at 08:15, Ville Skyttä wrote:
> > Some minor corrections and my IMHO, YMMV status:
> > 
> > I haven't really looked into cpan2rpm but I have made some improvements
> > to the perl-RPM-Specfile package (be sure to grab the fedora.us version
> > as all changes have been submitted upstream, but not applied yet).
>
> Good to know, but this is not enough.

I agree.  But for whatever reason, since people tend to use these tools
anyway, improving them shouldn't hurt.

> > Anyway, both cpanflute2 and cpan2rpm produce pretty obfuscated
> > specfiles.  Instead of using them, there's a bunch of perl-* packages in
> > the www.fedora.us/QA queue (and lots more not-yet-submitted ones at
> > cachalot.mine.nu/1/SRPMS.fdr/) which are based on a template which is
> > based on earlier discussions in bugzilla.fedora.us and fedora-devel at
> > fedora.us list.
> > 
> Still there are not enough packages handled to be useful for the masses
> of perl programmers.

But of course not.  I have no intention to package the whole CPAN, and I
hope nobody else tries it alone either :)  20-30 modules is pretty
manageable per packager though.

>   I myself typically end up requiring 20-30 modules
> for one project alone.  This has given me the motivation to pursue this
> fully and I intend to begin the process of creating packages for every
> perl module to start with, then automating building from there.

I have more confidence in packagers continuously cross-QA'ing each
others work than the above (alone).  Automating is good whenever it
makes sense though.

> > I've just submitted the specfile template to
> > https://bugzilla.fedora.us/show_bug.cgi?id=1010 for comments. 
> > cpanflute2 and/or cpan2rpm could possibly be tweaked more towards this. 
> > The main difference currently with the template and cpanflute2 is that
> > the template takes care of removing more unneeded files and bluntly
> > works around the unowned dirs issue in the past and current RH and FC
> > perl packages,
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=73970
> > 
> 
> I'm past thinking of using those automated cpan2rpm type tools.  I've
> gotten enough response where I feel that we need to handle each package
> individually and build a repository from there.

+1

> Contributions are more than welcome (of spec files of course).
> ATRPMs is willing to accept
> submissions, which works for me.  In the meantime I can host a testing
> repository for packages until something more formal is worked out.

I'm personally more comfortable with the fedora.us process, it has been
designed for submissions and has almost all the building blocks in place
already, even if there are some rough edges here and there.

> > For some weird reason, even though perl module packages (especially when
> > a template is consistently used) are trivial to review, the QA process
> > seems to take a long time.  Help is certainly welcome in this area.
> > 
> 
> It's not wierd at all.

Let me rephrase: I find the (lack|rarity) of reviews weird, given that
interested folks certainly exist.

>   It takes a long time to ensure that everything
> in a perl CPAN module is handled correctly.  And correctness is exactly
> what I'm striving for.  Little bugs will not do.  My intention is to get
> this started  right  from the get-go, that means cpan2rpm for instance
> is out.  Individual spec files need to be made for each module initially
> (although a template would be great for about half, and if you can help
> with this please let me know).  I appreciate any and all help, afterall
> we are a community (feel free to make suggestions or call me an idiot, I
> thrive off of criticism) ;-) 

Well, we seem to have similar goals.  I'd suggest taking advantage of
the fedora.us submission/QA procedures at least until the corresponding
fedora.redhat.com is completely up and running.





More information about the fedora-devel-list mailing list