I have written an internal Fedora RPM for web2py a while ago and tried to follow Fedora's packaging guidelines. I'm a RHEL/CentOS sysadmin and take care of quite a few hosting servers, my main objective was to easily use it on our RHEL/CentOS servers with Cherokee.
I don't want to "steal" the Debian related thread, but I'd like to comment and discuss some of the proposed changes since they are relevant to any OS packages, not only Debian. I found the following difficulties/questions when I created our RPMs: - web2py has a very rapid release cycle. That makes it difficult to get it in EPEL repository properly (for RHEL and CentOS), perhaps RPMFusion would be a better choice. If it gets in Fedora directly, CentOS and RHEL admins won't have optimal access to the package - I guess one should take a "stable" release and package it, than follow the changelog and make a new package every month or so. A new release every couple of days isn't going to work with distribution repositories, since packages go trough a prolonged testing phase. Backwards compatibility helps (great!) but still, one release per month is probably the best one can hope for - it must be possible to use a separate applications folder (in a sane manner, perhaps as ~/.web2py/applications in a user home folder and other places) - several locations of applications folder should coexist and get used by different end users, depending on how one starts web2py - these application folders belong to users, RPM doesn't touch them - does admin count as a regular application? How to update it? Should there be a single admin app per physical server? How to protect it and how to separate users? How to adjust this for different web servers? - how to disable updating and version checking from a web interface? It shouldn't happen when using an RPM (or .deb). I guess one could remove this functionality with a patch - all relevant web2py .py files should be compiled as .pyc at packaging stage since end users won't be able to achieve this. It also makes RPM upgrade and removal stages cleaner - RPM (or .deb, etc.) should not interfere with hosting customers who upload their own complete web2py - should there be a startup script that starts web2py with internal server or...? This isn't going to get used in an enterprise environment - how to deal with the choice of Apache, Cherokee, etc. I also don't see why gluon and other core files should be separated one from another, perhaps I'm missing something. Just the applications, documentation and perhaps the contributed scripts must be separated from the core/gluon. And what should be done with the admin app? I packaged web2py as: web2py-core we2py-admin web2py-examples The applications folder issues remained. Admin app was enabled for server administrator only, overwritten with upgrades. Example apps were overwritten with upgrades. The RPMs were closely linked with Cherokee but that was just for our internal use. I also made a separate README, provided sample scripts (conf, xml, etc.) for Apache mod_wsgi and Cherokee with uwsgi and let the admin set it up with a web server of his choice. I'd be glad to hear any comments and could maintain the RPM part of packaging if the issues get ironed out. Or I can just provide my .spec files to give a head start to a future RPM maintainer, it really doesn't matter. All this being said, there is still a fundamental question of packaging rationale. Should web2py get packaged at all? Or should it remain in userland alltogether, similar to CakePHP and various other frameworks of any kind. Various other web application packages such as phpmyadmin, etc. do get packaged, so... In any case, I'm going to keep maintaining the RPMs for our internal use and I'd appreciate any additional comments. Kind regards to all.
