[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Best practices on writing rockspecs for uncommon libraries
- From: Alexander Gladysh <agladysh@...>
- Date: Wed, 23 Mar 2011 14:31:26 +0300
On Wed, Mar 23, 2011 at 06:15, Hisham <email@example.com> wrote:
> On Tue, Mar 22, 2011 at 11:06 PM, Alexander Gladysh <firstname.lastname@example.org> wrote:
>> On Wed, Mar 23, 2011 at 04:33, Peter Drahoš <email@example.com> wrote:
>>> On Wed, Mar 23, 2011 at 2:12 AM, Alexander Gladysh <firstname.lastname@example.org>
>> If I will be considering an investment into a change of deployment
>> strategy I would rather try switching to Debian packages. LuaRocks
>> development is, sadly, too sluggish (no disrespect to the current
>> maintainers — this is my problem, not theirs).
> No offense taken. Like it was said, if it's practical, linking the
> library statically is a fine option for use with LuaRocks.
> Due to
> reasons including our limited development resources, LuaRocks will
> stick at what it knows best: being a simple option for building Lua
> modules and being a deployment tool for rocks.
Note that I did not suggest doing otherwise.
> For environments where
> you don't have the luxury of native system packages for external
> dependencies, LuaDist is an option for providing external dependencies
> in a cross-platform manner.
> I don't know if you're set into using either an all-LuaRocks or
> all-Debian deployment strategy, but I would consider using LuaRocks
> for Lua modules and Debian packages for non-Lua dependencies to be a
> sensible strategy.
That is reasonable — especially since it does not require me to
overhaul existing code.
For now I will bundle hiredis with the rock. If someone will create a
debian package for it, poke me, I will fix the rockspec. (At some
not-too-near point in the future I may create such package myself, but
don't count on it.)