On 16 oct, 15:40, 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. >
Great > 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. > Sure > 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 I totally agree > > - 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 We depend on Massimo and other web2py developers to achieve this. Massimo said he's working on it. So we should think this is going to happen. > - these application folders belong to users, RPM doesn't touch them > Of course > - does admin count as a regular application? I think it does - How to update it? With its package > Should > there be a single admin app per physical server? I think so >How to protect it and > how to separate users? One option would be adding a new system group (or using www-data) and all users in that group will have the same access. Another option would be symlinking the only admin application to the home directory of the user, so any user would be able to run it in his own environment. > How to adjust this for different web servers? In my opinion, we have to options: not do it, and giving examples and documentation on how to do it. Or doing it with different packages for every server. > - 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 Yes > - 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 Not in Debian packages. The package should contain only the .py files. In Debian and its derivatives, when a python package in installed, it will compile the .py files with the user Python version, and place the .pyc files in different directories depending on the user python version. > - RPM (or .deb, etc.) should not interfere with hosting customers who > upload their own complete web2py Of course, but I don't think this is a problem if we don't set it up with a web server. > - should there be a startup script that starts web2py with internal > server or...? This isn't going to get used in an enterprise > environment In the raw version (without web server setup) I think it shouldn't. it should be started manually by the user. > - how to deal with the choice of Apache, Cherokee, etc. > Not doing it at all, or doing it with different packages. > 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 > I think this is a very smart division. I'd only add a python-web2py metapackage with dependencies on all of the above. So if the user installs python-web2py, all the packages are automagically installed. > 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. I'd like to read your .spec file. I'm sure it can help in the Debian packaging as you've already worked in the same issues we've been discussing here. > > 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... > I think it should. Not only thinking in users wanting to use web2py, but in applications developed using web2py. In the future there will be applications made with web2py that we'll want to be in main Linux distributions. If we want those applications being in the repositories, a previous step is having web2py. In terms of Debian packaging we have to study deeply all the dependencies. Not only technical depedendencies but also legal ones. web2py includes several javascript files made by other people, and I want it to pass the legal exam in Debian. > In any case, I'm going to keep maintaining the RPMs for our internal > use and I'd appreciate any additional comments. > I thank you your comments, and I hope you can help in the Debian packaging too, as most problems (if not they all) are common to any distribution packaging. The final way of compiling the package differs, but I can't recall of any other difference. Regards. José L. > Kind regards to all.
