On Thu, Oct 14, 2010 at 7:12 AM, <[email protected]> wrote:
> Hmm, it's not as easy as traversing package.path like I dreamed;
> e.g. aptitude install liblua5.1-posix1 leaves its posix in
> /usr/lib/lua/5.1/posix.so --> /usr/lib/liblua5.1-posix.so.1.0.0
> which is not in the package.path
Yes, I noticed this with liblua5.1-gnome-0. But the symlink is in the
correct place.
> But, internally, Lua knows where to look for its modules...
> Is there an equivalent to package.path which would include
> the places where its *.so modules live ?
That would be package.cpath. Also, LuaRocks knows what modules are
under its control, it's all in the manifest, so one could do a
consistency check.
> Maybe luarocks could peek into /var/lib/dpkg and its rpm and
> windows equivalents ? (too pragmatic? too high-maintenance?)
It is awkward, because the platform type ('Linux') does not tell us
what the package manager is. You would end up with a lot of heuristic
checking. This functionality could be factored out as a new rock, but
it's a fair amount of work for the LR maintainer to track all the
native packages.
> There might be some hope of persuading dpgk, rpm and windows
> package-maintainers to invoke luarocks register posix 5.1.4
> in their post-install scripts ?
We could approach Enrico Tassi (the Lua Debian packager) and ask his
opinion. My main concern is that for LR to work reliably it does need
to know the version of the native package, or at least establish a
reliable lower bound.
steve d.
PS. As for Windows, it would be _nice_ if there were package managers.
For people using LfW, we know exactly what the base non-LR install
is. OS X has fink and macports, similar issues to dpkg etc.
_______________________________________________
Luarocks-developers mailing list
[email protected]
http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
