On 14 oct, 17:24, Mark Breedveld <m.breedv...@solcon.nl> wrote: > I've not so much time. > But we have done this discussion before. > There where three problems with packaging web2py. > > - Really frequent release period (not impossible for someone with a > lot time)
I've already answer this before: Debian sid for frequent uploads, debian stable for stable servers (with security patches). The frequency the package is updated will depend on how much web2py changes between releases. With a good packaging it may take five minutes recompiling the package. Also, if the packaging is done via a group of people working together in alioth.debian.org it may be updated very often. > - Difficult to implement according the packaging guidelines That's where I think I can help, with the help of others who know better the internals of web2py to solve the problems that may arise. > - Difficult to implement with user separation It's related to the above problem, but I think it can be done. > - (Too) many configuration possible >From my point of view the package only should provide one possible configuration, the less intrusive (in terms of changing user configurations): use the rocket server and sqlite. It may also provide Readme or example files to configure apache, or other servers, but that's something not needed to begin to work with web2py. Configuring a server is done to put a server in production, and that's something that, in my opinion, should always be done manually, not automatically by installing a package. > > If we solve the above and find someone with enough time. Yes, that > would be perfect and I would support that. > > The application I have in mind looks like webmin, ecplipse IDE (plugin > framework), netbeans (plugin framework). A kind of universal installer > for web2py. This situation would mean the web2py is plugin in the > system. Every plugin has its own capability's and configuration. like > - Apache ( wsgi+ web2py + mysql + jailroot ) > - http ligth + web2py + postgres > > But the first release would contain a simple plugin. > Just web2py in some folder under some user. > > And the internal updater of web2py is used to update it. > > But if you say that this is not allowed. It's not allowed as a Debian package inside Debian repositories, but you can do a Debian package with it inside for your personal use, or to put it in a web2py download page. > Then there is only one thing to do. > Find a company or person which has explicit benefit or/and willing to > contribute a large amount of time by packaging. > He/They would become the Release manager of web2py. > I think I don't understand what you mean or what you would like to do. A package maintainer is not a release manager of the application. The package maintainer always works with upstream, and after upstream has released. It doesn't matter the way upstream releases, and, obviously, the release manager must be some of the upstream team. The package maintainer doesn't need to be part of the upstream team. He just pick up the sources and make a package that fullfils the distribution packaging guidelines. I want to have a Debian package of web2py, so I volunteer to work on it, but I do not want to be part of the web2py release team. I think Massimo is doing a great work with the help of many people who know of Python and web development much more than me . Also, I don't have any interest in releasing for Mac, windows, or even Red Hat. I am just a Debian Developer who is using web2py, knows the internal of packaging, has permissions to upload new software to the official Debian repository, and would like to have it in Debian. So far, so good. No more ambitions, no more needs. Regards José L.
