Thanks this is a helpful comment. I will ty to answer some questions although I do not have an answer.
On Oct 16, 8:40 am, LightDot <light...@gmail.com> wrote: > 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 This means these users will be always behind. :-( > - 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) We are working on it. > - several locations of applications folder should coexist and get used > by different end users, depending on how one starts web2py This will be possible when previous point is addressed. Soon. > - 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? Do not know. that is the problem. Web2py is designed to give a lot of control to users. Packaging one set of *.py files takes away such control. > - 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 Why disable the check? Because upgrade would not work (true)? > - 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 This should not be a problem. > - 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.
