[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] LuaRocks 2.0.13
- From: TNHarris <telliamed@...>
- Date: Thu, 18 Apr 2013 14:12:38 -0400
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.