On 21 March 2016 at 11:37, lumin <cdlumin...@gmail.com> wrote:
> Package: lua5.1-policy
> Version: 33
> Severity: wishlist
> X-Debbugs-CC: debian-de...@lists.debian.org, h...@hisham.hm
>
> Hi,
> (Talking about policy, hence CC'ing -devel)
> (CC'ing luarocks upstream)
Thank you for the initiative!
> When I'm dealing with one of my ITP's I found that this is
> a noticeable problem to Debian's lua packages. And I think
> this may require some changes to our lua policy, or the dh-lua
> scripts.
>
> Luarocks is a lua module manager, just like pip to python.
> However Debian's luarocks is blind to Debian's lua modules,
> i.e. `luarocks list` won't list lua modules installed by dpkg,
> besides, lua modules installed by dpkg won't participate
> lua module dependency resolution, that's bad.
>
> When pulling new lua modules from the internet with `luarocks`,
> it will scan lua module dependency and automatically pull missing
> modules and install them. For example, I need to install a lua
> module that is not packaged by us, say lua-xxx, and it depends
> on lua-cjson. Then `luarocks install xxx` will cause luarocks
> to install a new lua-cjson module, ignoring the lua-cjson package
> installed by dpkg. Why do we provide lua-cjson package?
>
> *** What to do to make improvement? ***
>
> IMHO following changes should be considered:
>
> 1. update default configuration file of luarocks
> /etc/luarocks/config-5.1.lua
>
> ```patch
> rocks_trees = {
> home..[[/.luarocks]],
> [[/usr/local]],
> + [[/usr]],
> }
> + deps_mode = 'all'
> ```
The original docs I wrote about this had an error: it's important that
"/usr/local" remains the last entry in this list (it is the one picked
by default by LuaRocks when making system-wide installations. I
recomend using this:
```lua
rocks_trees = {
{ name = "user", root = home.."/.luarocks" },
{ name = "distro-modules", root = "/usr" },
{ name = "system", root = "/usr/local" },
}
deps_mode = "all"
```
This allows users to use named trees such as --tree=user, and matches
the "user" and "system" entries that LuaRocks creates by default when
there is no config file.
> 2. let luarocks package install this directory
>
> /usr/lib/luarocks/rocks/
>
> 3. update lua-* packages with luarocks integration,
> e.g. update their postinst and prerm scripts.
>
> To this point I have a solution that works but is not good enough:
> (patch parts copied from my locally modified lua-cjson package)
>
> ```patch
> --- /dev/null
> +++ b/debian/lua-cjson.postinst
> @@ -0,0 +1,31 @@
> +#!/bin/sh
> +set -e
> +
> +prepare_luarocks ()
> +{
> + local rockdir
> + rockdir='/usr/lib/luarocks/rocks/lua-cjson/2.1.0-1/'
> + mkdir -p $rockdir
> + echo 'rock_manifest = {}' > $rockdir/rock_manifest
> + cp /usr/share/doc/lua-cjson/lua-cjson-2.1.0-1.rockspec $rockdir
> + if [ -x /usr/bin/luarocks-admin ]; then
> + luarocks-admin make-manifest --local-tree --tree=/usr
> + fi
> +}
> [...]
> ```
>
> and this one
>
> ```patch
> --- /dev/null
> +++ b/debian/lua-cjson.prerm
> @@ -0,0 +1,27 @@
> +#!/bin/sh
> +set -e
> +
> +remove_luarocks ()
> +{
> + if [ -x /usr/bin/luarocks ]; then
> + luarocks remove lua-cjson --local-tree --tree=/usr
Since the directory structure under /usr/lib/luarocks was generated by
hand I suspect using `luarocks remove` like this could cause failures.
I'd go for a more "manual" approach mirroring that of
prepare_luarocks, but if this works I guess it's fine. In any case
--local-tree is not necessary in this line: it is a flag specific to
`luarocks-admin make-manifest`.
Thank you for working on this! I get lots of requests from users for
updated Debian/Ubuntu packages and have been asked a number of times
for this kind of integration functionality.
-- Hisham
