Re: [ANN] LuaRocks 2.0.13

[TNHarris <telliamed@...>]

On Wednesday, April 17, 2013 06:00:21 AM steve donovan wrote:
> It's doable, but does involve some legwork. E.g. start out with 'fake'
> rockspecs defining the exact _version_ of the several dozen Lua packages
> available in Debian, and if a user has already got luasocket from apt-get,
> then regard that as satisfying a dependency. The Problem happens when the
> user wishes to move to a new shiny luasocket, and that's when we have to
> speak the package manager's language.

There are so many different packaging systems though, I don't think this is 
realistic. Making LR aware of system packages is, as you say, not to 
difficult. But LR should only be in the business of installing LR packages.

It would be silly for a system package to depend on a rock. So telling apt 
that there's a new version of luasocket is frivolous. All the other packages 
apt knows about depend on the older version. The only dependency on the newer 
version will come from other rocks. Thus there's no harm in LuaRocks only 
providing dependency information to its own ecosystem.

In the other direction, providing dependency information from the system to 
LR, is already possible by creating a manifest on the already installed 
packages. Then it becomes apt's responsibility to keep the manifest in sync, 
since apt knows more about the packages its installed than LR does. The 
luarocks-admin tool can create manifests, but it could be made more flexible 
with options to insert/remove an individual package from the tree. 

In summary, putting any kind of third-party package logic into LuaRocks does 
not seem sensible to me.

-- 
tom <telliamed@whoopdedo.org>