You have the idea. Thanks for clearing it towards the others. My guesses it we need to do both. Because Jose goal is general purpose and mine aswell, but comes with overkill in the most cases.
In Jose case I would suggest a slight change. web2py-core web2py-gluon This has been discusses before, I recall you where in those discussions Jose. http://groups.google.com/group/web2py/browse_frm/thread/45ea4327d713bdd8/f4a9c8160432cfbb?hl=en&lnk=gst&q=debian#f4a9c8160432cfbb http://groups.google.com/group/web2py/browse_frm/thread/51b731d9abb5270d/550ed09fbf7af9f2?hl=en&lnk=gst&q=debian#550ed09fbf7af9f2 There are some other topics, search for turnkeylinux, where this is mentioned. I recall Dimo Barsky was busy with packaging Gluon, but I've been out for a while. I don't know him, but he might help with this. It was chaos post again, but I hope this one helps:p. Mark, On 14 okt, 23:51, Christopher Steel <chris.st...@gmail.com> wrote: > If your break things down into one or more “debian” packages and at > least one web2py application you could end up with a phenomenally > powerful and easy to maintain setup that could have resounding > repercussions, so to speak, for all parties. > > How does the following example sound? > > Package 1, web2py > > sudo apt-get install web2py > > unpacks a stable version of web2py to the users home directory if one > does not exist. > > /home/mary/web2py/web2py > > Adds scripts for starting, stopping and restarting web2py using the > web2py *built in* web server. An option to install to a directory > other than the “default” can be made available as well. > > Advantages > - Always works > - Does not break anything, ever > - Easy to customize > - Highly portable > - Can start developing right away > - Easy to implement > - easy to clean up via apt-get purge and so on. > - easy to backup, delete, upgrade etc. > > Disadvantages > - Might be hard to justify doing a dissertation on this, but using > Package X the sky is the limit ;) > > Package X example, web2py universal installer > > sudo apt-get install universal-web2py > > If the web2py package is not installed it gets installed, if mercurial > is not already installed it gets installed. If a clone of the web2py > application called “universal installer” does not exist, it is created > in ${HOME}/web2py/web2py/applications. if web2py is not running it > starts it and opens default browser to the universal application. > > The universal application can do almost anything you like then and you > would easily create additional packages and so forth in this way. > > People who want a “server installer” can create a “server installer” > web2py application and /or debian package that could be made available > via your universal installer. > > Sounds cool! > > Cheers, > > Christopher Steel > > Voice of Access > > On Oct 14, 3:36 pm, Mark Breedveld <m.breedv...@solcon.nl> wrote: > > > Well that makes a hope clear. > > I learned a lot from your explanation. > > > You did rule out almost the obstacles. > > And the last one should solve able. > > Changing some process within web2py. > > > I need this for my project. > > So if you need anything, please let me know. > > Direct mail will grantee answer... > > > and all try to follow this topic. > > > Mark, > > > On 14 okt, 20:03, José L. <jredr...@gmail.com> wrote: > > > > 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. > >
