Hello all,
Are there plans to bring the perl Catalyst framework to EPEL 6? The runtime and many of the plugins are already in Fedora 12. I am interested in providing any help that is needed; however, I have never created any packages for either Fedora or EPEL.
On Sat, Aug 21, 2010 at 13:36, Edward Trochim ejtrochim@alaska.edu wrote:
Hello all,
Are there plans to bring the perl Catalyst framework to EPEL 6? The runtime and many of the plugins are already in Fedora 12. I am interested in providing any help that is needed; however, I have never created any packages for either Fedora or EPEL.
No one has expressed an interest before. I would say that the first thing to look for is help in the Fedora Perl SIG
http://fedoraproject.org/wiki/SIGs/Perl http://fedoraproject.org/wiki/Catalyst https://admin.fedoraproject.org/mailman/listinfo/perl-devel
There you would get the best answers on who could help you on getting this into EPEL.
On Sat, Aug 21, 2010 at 11:36 PM, Stephen John Smoogen smooge@gmail.com wrote:
On Sat, Aug 21, 2010 at 13:36, Edward Trochim ejtrochim@alaska.edu wrote:
Hello all,
Are there plans to bring the perl Catalyst framework to EPEL 6? The runtime and many of the plugins are already in Fedora 12. I am interested in providing any help that is needed; however, I have never created any packages for either Fedora or EPEL.
No one has expressed an interest before. I would say that the first thing to look for is help in the Fedora Perl SIG
It certainly seems possible. I only find 40 missing deps for a minimal installation. The biggest problem is that last time I checked, Chris Weyl wasn't interested in EPEL.
berrange perl-Array-Diff berrange perl-Module-CPANTS-Analyse * cweyl perl-Catalyst-Action-RenderView cweyl perl-Catalyst-Devel cweyl perl-Catalyst-Plugin-ConfigLoader cweyl perl-Catalyst-Plugin-Static-Simple cweyl perl-Catalyst-Plugin-SubRequest cweyl perl-Catalyst-Runtime cweyl perl-Class-C3-Adopt-NEXT cweyl perl-Config-Any cweyl perl-Data-Alias cweyl perl-Data-Dump * cweyl perl-Data-Visitor cweyl perl-File-ChangeNotify cweyl perl-File-Modified cweyl perl-HTTP-Request-AsCGI cweyl perl-MooseX-Emulate-Class-Accessor-Fast cweyl perl-MooseX-MethodAttributes cweyl perl-MooseX-Params-Validate cweyl perl-MooseX-SemiAffordanceAccessor cweyl perl-namespace-autoclean cweyl perl-String-RewritePrefix cweyl perl-Test-use-ok cweyl perl-Text-SimpleTable cweyl perl-Tie-ToObject cweyl perl-Tree-Simple-VisitorFactory eseyman perl-Variable-Magic iarnell perl-Devel-Hide iarnell perl-Term-Size-Any iarnell perl-Term-Size-Perl iburrell perl-Path-Class * lkundrak perl-Test-MockObject * spot perl-UNIVERSAL-can * spot perl-UNIVERSAL-isa * steve perl-Devel-Caller * till fcgi * tremble perl-B-Hooks-EndOfScope * tremble perl-MooseX-Types * tremble perl-namespace-clean * tremble perl-Test-Kwalitee *
(*) already exists in EPEL, but no builds for EL-6 yet.
On Saturday 21 August 2010, Edward Trochim elucidated thus:
Hello all,
Are there plans to bring the perl Catalyst framework to EPEL 6? The runtime and many of the plugins are already in Fedora 12. I am interested in providing any help that is needed; however, I have never created any packages for either Fedora or EPEL.
Is there a preference to not simply install it from CPAN? That would be my choice: the packages would stay much more up to date, vs. the EPEL update cycle.
Just wondering.
j
On Mon, 23 Aug 2010 11:20:59 -0800 "Joshua J. Kugler" joshua@eeinternet.com wrote:
On Saturday 21 August 2010, Edward Trochim elucidated thus:
Hello all,
Are there plans to bring the perl Catalyst framework to EPEL 6? The runtime and many of the plugins are already in Fedora 12. I am interested in providing any help that is needed; however, I have never created any packages for either Fedora or EPEL.
Is there a preference to not simply install it from CPAN? That would be my choice: the packages would stay much more up to date, vs. the EPEL update cycle.
Just wondering.
Personally, I find mixing CPAN installs and installs from rpm to be very problematic. The issue is that sometimes CPAN will decide to upgrade something you have installed via rpm (like say, perl itself) and mess up all other packages installed from rpm. Also, on the other side, rpm packaged modules may upgrade something you installed from CPAN and cause breakage there.
So, my suggestion would be to stick with one and only one package management system. In my case rpm/yum. :)
kevin
My organization handles all software deployments to our several dozen production systems through yum; whether it is in-house or third party software. It greatly eases update management for us.
We are seriously considering using Catalyst for a new webapp we will be developing soon and we want to be able to deploy it using the same mechanisms as all our other software. We could use CPAN, and we are prepared to go that route if we need to, but we would prefer to keep everything in RPMs. There are actually several deployment strategies I am investigating right now, this is just one of them.
On Aug 23, 2010, at 11:20 AM, Joshua J. Kugler wrote:
On Saturday 21 August 2010, Edward Trochim elucidated thus:
Hello all,
Are there plans to bring the perl Catalyst framework to EPEL 6? The runtime and many of the plugins are already in Fedora 12. I am interested in providing any help that is needed; however, I have never created any packages for either Fedora or EPEL.
Is there a preference to not simply install it from CPAN? That would be my choice: the packages would stay much more up to date, vs. the EPEL update cycle.
Just wondering.
j
-- Joshua Kugler Part-Time System Admin/Programmer http://www.eeinternet.com - Fairbanks, AK PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
Hello...
On Mon, 2010-08-23 at 11:46 -0800, Edward Trochim wrote:
My organization handles all software deployments to our several dozen production systems through yum; whether it is in-house or third party software. It greatly eases update management for us.
We are seriously considering using Catalyst for a new webapp we will be developing soon and we want to be able to deploy it using the same mechanisms as all our other software. We could use CPAN, and we are prepared to go that route if we need to, but we would prefer to keep everything in RPMs. There are actually several deployment strategies I am investigating right now, this is just one of them.
cpanspec ( also in EPEL ) is designed to generate rpm packages from CPAN packages. In my previous job I generated many internal perl rpms and cpanspec was by far the best tool of several I used. You shouldn't have too much trouble doing it yourself.
<snip>
cpanspec ( also in EPEL ) is designed to generate rpm packages from CPAN packages. In my previous job I generated many internal perl rpms and cpanspec was by far the best tool of several I used. You shouldn't have too much trouble doing it yourself.
If each shop is doing it themselves, that's a lot of wasted productivity over the long haul. Ideally, this is done in EPEL which will handle the default case (which is hopefully good enough for most shops). After that shops may require adjustments to packages or produce newer ones in year 3-7 of the RHEL lifecycle. I'd hope that EPEL can at least be a decent starting point though.
Mike
Once upon a time, Michael Stahnke mastahnke@gmail.com said:
If each shop is doing it themselves, that's a lot of wasted productivity over the long haul. Ideally, this is done in EPEL which will handle the default case (which is hopefully good enough for most shops). After that shops may require adjustments to packages or produce newer ones in year 3-7 of the RHEL lifecycle. I'd hope that EPEL can at least be a decent starting point though.
I package up several things myself, mainly because I need it "now". I have plans to push some of those packages to Fedora and EPEL (or just EPEL, in the case of local rebuilds of Fedora packages), but I haven't had enough round tuits to get that done.
I did separate my local RHEL repo into repos based on the source of the package, like "fedora-add" for things I've rebuilt from Fedora, "fedora-replace" for a few things where I needed a newer version than RHEL/EPEL, "hiwaay-add" for my packages, etc. Ideally that will make it easier for me to work with Fedora and EPEL to get my work into the repos.
On Aug 23, 2010, at 12:07 PM, Christopher McCrory wrote:
Hello...
cpanspec ( also in EPEL ) is designed to generate rpm packages from CPAN packages. In my previous job I generated many internal perl rpms and cpanspec was by far the best tool of several I used. You shouldn't have too much trouble doing it yourself.
I've used that tool before and I really like it. In this case however, I would probably just rebuild the SRPMs from Fedora due to the number and complexity of the dependencies. But before I did that I wanted to make sure that I wasn't going to duplicate any work that was going to show up in EPEL. Also, having Catalyst in EPEL might be useful for other people.
Edward Trochim wrote:
We are seriously considering using Catalyst for a new webapp we will be developing soon and we want to be able to deploy it using the same mechanisms as all our other software. We could use CPAN, and we are prepared to go that route if we need to, but we would prefer to keep everything in RPMs. There are actually several deployment strategies I am investigating right now, this is just one of them.
Are you already a Fedora Packager? If so then cweyl seems quite happy to let people maintain his packages over in EPEL.
The packages I've not built yet in that list are because I've not had chance to chase done the last few dependencies and I've been on holiday and am about to move country. I'm willing to help co-maintain the extra packages in EPEL, but I'm unlikely to be doing that much over the next 2 to 3 weeks.
Mark
On Tue, Aug 24, 2010 at 11:59 AM, Mark Chappell tremble@tremble.org.uk wrote:
Edward Trochim wrote:
We are seriously considering using Catalyst for a new webapp we will be developing soon and we want to be able to deploy it using the same mechanisms as all our other software. We could use CPAN, and we are prepared to go that route if we need to, but we would prefer to keep everything in RPMs. There are actually several deployment strategies I am investigating right now, this is just one of them.
Are you already a Fedora Packager?
In his original post, Edward indicated that he's not.
If so then cweyl seems quite happy to let people maintain his packages over in EPEL.
The packages I've not built yet in that list are because I've not had chance to chase done the last few dependencies and I've been on holiday and am about to move country. I'm willing to help co-maintain the extra packages in EPEL, but I'm unlikely to be doing that much over the next 2 to 3 weeks.
I'd be happy to co-maintain cweyl's packages with you. I'll fire off a bunch of SCM admin requests later today and start pushing some builds.
On Aug 24, 2010, at 8:11 PM, Iain Arnell wrote:
On Tue, Aug 24, 2010 at 11:59 AM, Mark Chappell tremble@tremble.org.uk wrote:
Are you already a Fedora Packager?
In his original post, Edward indicated that he's not.
This is correct.
If so then cweyl seems quite happy to let people maintain his packages over in EPEL.
The packages I've not built yet in that list are because I've not had chance to chase done the last few dependencies and I've been on holiday and am about to move country. I'm willing to help co-maintain the extra packages in EPEL, but I'm unlikely to be doing that much over the next 2 to 3 weeks.
I'd be happy to co-maintain cweyl's packages with you. I'll fire off a bunch of SCM admin requests later today and start pushing some builds.
This sounds fantastic. Thanks to both of you for your help.
On Wed, Aug 25, 2010 at 6:59 PM, Edward Trochim ejtrochim@alaska.edu wrote:
This sounds fantastic. Thanks to both of you for your help.
Okay, phase 1 is just about complete. Between us, Mark and I got everything for perl-Catalyst-Devel built (and mostly updated to latest version from CPAN). To be useful, though, I guess we need model and view too. There's another handful of deps for Catalyst::Model::DBIC::Schema and Catalyst::View::TT, again mostly owned by Chris (Heap and Class-Unload are Marcela's).
perl-Graph (*) perl-Path-Class (* needs updating in EPEL to 0.18) perl-Spreadsheet-ParseExcel (*) perl-Heap perl-Catalyst-Model-DBIC-Schema perl-Catalyst-View-TT perl-CatalystX-Component-Traits perl-Class-Accessor-Grouped (needs updating to 0.09005 in rawhide) perl-Class-Base perl-Class-C3-Componentised perl-Class-DBI-Plugin-DeepAbstractSearch perl-Class-MakeMethods perl-Class-Unload perl-Context-Preserve perl-Data-Dumper-Concise perl-DateTime-Format-Pg perl-DateTime-Format-SQLite perl-DBIx-Class (needs updating to 0.08123 in rawhide) perl-DBIx-Class-Schema-Loader perl-JSON-Any perl-MooseX-Traits-Pluggable perl-MooseX-Types-JSON perl-MooseX-Types-Path-Class perl-SQL-Translator (needs updating to 0.11006 in rawhide) perl-Template-Provider-Encoding perl-Template-Timer perl-Text-RecordParser perl-Text-TabularDisplay
and one new package for Math-Base36 is required to build the latest version of DBIx-Class. If Mark doesn't beat me to it, I'll fire off another bunch of branch requests and start building these too.
(*) already branched - just needs to be built
epel-devel@lists.fedoraproject.org
-
Chris Adams -
Christopher McCrory -
Edward Trochim -
Iain Arnell -
Joshua J. Kugler -
Kevin Fenzi -
Mark Chappell -
Michael Stahnke -
Stephen John Smoogen