CPAN RPM archive?

Stan Bubrouski stan at ccs.neu.edu
Mon Dec 1 19:37:45 UTC 2003


On Mon, 2003-12-01 at 14:06, Ville Skyttä wrote:
> [fedora-devel-list back to Cc and quoted in full, I don't know if the
> copy was accidentally omitted]
> 

Was a pm.  Heh.  Don't worry about it.


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

I agree, but I don't feel like taking on anything that complicated.


> 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 know that's why I want some help doing.  I do however want all of CPAN
packaged.  This is something I think all distributions lack and
something the community would definitely want.

> >   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 think the QA process is fine, but I think it would be burdonsome for
the process.  I dunno.

> > > 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.
> 

Ok agreed, but this probably needs to coordinated externally to get it
up and running.

> > > 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.
> 

Heh that makes more sense than what I thought you were saying.  Agreed.

>  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.
> 

Ok so lets try to get some volunteers and get into planning :)


-sb

> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
> 





More information about the fedora-devel-list mailing list