I've made some replies privately that I want to take public. Here they are. Oh and turns out I added a few things too.
>> We considered Catalyst but our target platform (CentOS 5) doesn't seem >> to support it well. We try to stick to RPM packages at all costs so this >> is an additional constraint here. At this point, we were thinking about >> experimenting internally with Dancer, Mojolicious and another I can't >> remember now. > I see. Well, perl-Catalyst-Runtime is packaged in flexbox and rpmforge > for CentOS 5. Although in this case, Catalyst version is a little old, > and wouldn't work with a Perl server like I mentioned below. But not too > much, though. What exactly were the problems you found with Catalyst in > CentOS? On CentOS 5 I simply wasn't able to install it with packages. cpan was required and even then it took longer than the couple of hours I planned on it. This was a year ago. But Francis tried the RHEL6 packages lately and was able to do some development quickly with only few missing things that we'll be able to package ourselves (or submit to repoforge). He successfully did a PoC where we migrated our switch configuration bakc-end in bin/pfcmd to the framework with success. Also, when he showed me the developer friendly-ness of the embedded development server I must say I was very impressed. Also, Mojolicious 2.0 bumped their minimum requirements to perl 5.10 so no RHEL5 for them (unless we package perl...) and so it simplified the framework choice. > > Wouldn't it be a better practice to package non-core modules inside > PacketFence itself? Using local::lib, for instance. That way, you'd be > sure it would work on every system (CentOS 4, 5, 6, etc) the same way, > because there would be the same module version. Unless you really need > to use RedHat provided rpms, which, in Perl related stuff, I'm not sure > it's much better than grabbing the modules directly from CPAN, anyway. > (I realize I might be talking nonsense here, and if so, please forgive > my ignorance! It's an honest question) If we ever want to get 'upstreamed' in the distribution repository, inlining (using local::lib) packages is a no go. Also, tracking cpan for security fixes will definitely be a burden when you need to track hundreds of deps. And compiling the XS packages ourselves on several different servers is also work.. We have been thinking about this localize vs upstream dependencies trade-off since a little while and we didn't make a move yet. There's no easy answer. Regards, -- Olivier Bilodeau obilod...@inverse.ca :: +1.514.447.4918 *115 :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org) ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Packetfence-devel mailing list Packetfence-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-devel
