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.

Reply via email to