[Sputnik-list] Versium, which repo?

[Enrico Tassi]

On Sat, Dec 29, 2007 at 07:01:19PM -0800, Yuri Takhteyev wrote:
> LuaRocks is doing a great job.  However, it perhaps would make sense
> to see Debian package system as an alternative to LuaRocks.  I.e.,
> much like Sputnik "rock" has a dependency on several versium,
> luafilesystem, markdown, etc. rocks, it might make sense that sputnik
> package for debian would depend on a debian package for versium, lua
> markdown, lfs, etc.  I am saying "might" simply because I am not an
> expert on debian packaging system and I really don't know what would
> and would not make sense there.  Just an idea.

That is exactly what I plan to do. The dependencies the Debian packaging
system can express are at least expressive as the ones luarocks provide, 
thus I can mimic them. I may also be able to support the CGILua and
wsapi models concurrently, making sputnik depend on wsapi|cgilua (and
the wiki setup script will then have to detect which model to follow).

> The same would theoretically apply to plugins: it should be possible
> to install a plugin manually (with some work, that is), to install it
> with just something like "luarocks install sputnik-tickets" for a
> LuaRocks based installation or, potentially, package a plugin as a
> debian package.  The serious question is the following: if debian
> package is installed without Rocks but most plugins are not available
> as debian packages, people who install Sputnik as a debian package
> will be out of luck when it comes to plugins.  (Or, rather, they will
> be able to install them manually, but that would be more work.)

I agree with you, rocks and Debian packages have to be orthogonal. I
would like to package every "core" module with Debian packages, and all
plugins will be easily installable with rocks (in /usr/local/ or in
directories local to the wiki installation). Clearly, installing them by
hand would be a bit more work, since you have to care about the
installation path and so on, but I want it to be feasible. But until I
have core packages working, I'll not spend time on luarocks.

> way that makes them work together.  From this point of view, the
> debian package system would also be somewhat of an alternative to the
> Kepler 1.1. installer, right?  So, what is the relation then between
> the debian package system and "Kepler 1.1"

Yes, I see Kepler as an all-in-one module. I'm packaging almost all its
components separately. I could also provide a so called Debian
meta package that just depends on other packages without providing any
file. In any case, I prefer to have real applications like sputnik or
Xavante depend on some/many/most of these modules, rather than an empty
meta package.

> I believe 'require"luarocks.require"' only shows up in installer.lua
> and in cgilua/config.lua.  You can safely comment it out in both.
> Again, if the debian package system can satisfy all the dependencies,
> it should all work fine without rocks.

Thanks, I was hoping that.

> Perhaps, but let's talk about it a bit first.
> 
> First, it's quite easy to do that now, even though there isn't a
> script for that:
> 
> 1. Install Kepler system-wide
> 2. Keep cgilua/config.lua as is
> 3. Put cgilua_sputnik.lua into htdocs (as currently)
> 4. Use sputnik.cgi/cgilua_sputnik.lua as your BASE_URL
> 
> However, I think Sputnik's dependency on CGILua is quite unnecessary
> now that WSAPI is out and is included with Kepler by default.  So,
> instead, I want to port Sputnik to WSAPI, which really just means
> writing an alternative to cgilua_sputnik.lua.  In other words,
> cgilua_sputnik.lua is a 40-line adapter between Sputnik and cgilua.
> Now I want to write an adapter for WSAPI.  With this adapter, it would

In Debian cgilua will recommend wsapi, but will not depend on it since I
packaged it with the basic environment variable based SAPI
implementation made by Kepler and I shipped it with cgilua (so that if
you just want to write a regular cgi with Lua you can install cgilua and
you are done)

Wsapi brings with it a lot more, I divided the package in two so that
the fastcgi part is not required by default but it still depends on
rings, thus I don't see wsapi as something much smalled then cgilua, but
more as an extra layer to put between the web server and cgilua to
obtain extra features (maybe I'm wrong, please correct me) or as an
alternative to cgis.

Thus all solutions (a pure cgilua (I think it is possible), the current
cgilua + wsapi and the pure wsapi one) are fine, but It is hard for me
to grasp the pros and cons. Maybe your vision is much clearer than mine.

> paths.   And you'll also have to make sure that you have all the
> dependencies: a few Kepler pacakges (luafilesystem, md5, logging),
> markdown, and a few of my packages that I was thinking of distributing
> separately from Sputnik (versium, cosmo, colors).  (The latter
> packages can of course be also distributed together).

I was planning to package cosmo and versium separated, cosmo is useful
even alone and I'm already using it to generate rss feeds, versium is a
bit more tied to some kind of applications like wiki or cms but is still
wort having it separated I think. I've their packages almost ready (what
is missing is some doc and an official tarball with a COPYING file).

Colors, I don't know what it is meant for... 

> appreciate your offer to help and I hear your concerns.   Let's just
> make sure we don't end up re-implementing luarocks.

Sure, this is out of question. I want it to interact with the Debian
packaging system nicely, not to rewrite it. 

I'll stay tuned, hope Kepler and Sputnik will be released soon. When
your wiki will be almost in shape for a release please ping me so that I
try to package it again, and possibly contribute to the wiki setup
script (If I understood correctly it is something useful, even if it 
will be probably easy to write it).

Cheers
-- 
Enrico Tassi