IMHO I would not separate anything. A big part of Web2py's magic is that you do don't need to "install" it. Keeping everything together insures that upgrades will always work via the web2py web interface (with a pleasant side effect being that you do not have to repackage each time Web2py is updated so you get to spend more time doing what you love ;)
Other matters in no particular order... If you want "debian" startup scripts you could do it the way you mentioned, the formal "debian way" or the "web2py" way or some combination. You might consider placing them in the web2py/scripts directory (if Massimo if OK with that). This would make them easy to update (ie. no (debian) repackaging required) and they would be available to all Web2py users and developers. I think web2py/scripts/web2py.ubuntu.sh has a startup example. I the way it is done in the Ubuntu script work on all other debian systems. Project X Project X could be a Debian package containing a "companion" web2py application. In this case, for Debian users / developers. The idea being again to free you from the drudgery of repackaging when you (and optionally others if you so choose) want to update the companion application. I mentioned the possibility of using a mercurial clone as this would give you the freedom to add additional features, customizations and updates to the companion application, again without needing to update any debian packages. It has a lot of other very interesting "side effects" as well including creating a mechanism (via mercurial) that allows allows other web2py users to contribute to the application, so if you chose to do so it could become a web2py community application. By "not" automating companion application updates you give package users "full control". Advantages - Flexibility - Ability to update the package x companion application without repackaging. - Transfer of application maintaining is trivial. - Others can easily contribute to the package x companion application by installing package. - Keeps everyone focused on Web2py. - Did I mention it is really cool! Disadvantages - Requires maintainers for the two debian packages and one web2py application. - Too flexible? Universal Installers and so on. A setup similar to this opens the door to all the possible things that one can do with Web2py applications including providing instructions, links to additional debian packages, apt url installers, chats, twitter, scripts, server monitoring tools, video instructions, deployment tools and the list goes up to and including a "Universal Installer" if one where so inclined. The point being that a Debian package that including a companion application allows you (or others if you so choose) to add almost any additional feature at any time without the need to repackage and redistribute a Debian package, although this would also be possible if one chose to do so... Wow , that was really tough to describe in an email! Keep rockin, Cheers, Chris On Oct 15, 1:06 pm, José L. <jredr...@gmail.com> wrote: > On 15 oct, 13:32, Mark Breedveld <m.breedv...@solcon.nl> wrote: > > > > > 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/45ea4327d713b... > > >http://groups.google.com/group/web2py/browse_frm/thread/51b731d9abb52... > > > 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, > > Thanks, but after looking for more info in the links you provided, I > have not been able to find the rationale > for a separate gluon and core packages. > > can anybody enlight me?
