Re: To all Lua rock maintainers, take 2 (now with human-friendly reporting), you help is appreciated again

[Stefano <phd.st.p@...>]

On 16 Sep 2015 12:59, "Alexey Melnichuk" <alexeymelnichuck@gmail.com> wrote:
>
> Hello, Stefano.
>
>
> > Please let me know if something is still unclear.
> > Stefano
>
> > odbc    0.1.0-302       Windows x86     excluded        depends on external library
>
> On Windows it has not external dependencies.

Yes, I am not even parsing the dependencies info.
Will revise this when I introduce OS-specific packages.

>
> > lzmq-ffi 0.4.3-102       Windows x86     no      contending module "lzmq" with "lzmq-auth~0.1.0-2"
>
> This is not fully correct.
>
> lzmq/lzmq-ffi  provide  same API but one implemented on C and other on
> LuaFFI/LuaJIT FFI
>
> lzmq.auth/lzmq.pool can work ether with lzmq or lzmq-ffi.
> They also did not have conflicts with each other.
> But  because  LuaRocks  did  not supports optional deps I just did not
> point it in rockspecs.
>
> lzmq.timer   is   module   that  has  no  external  deps.  It  install
> `lzmq.timer`  module which provide absolute/monotonic timers. It works
> on Win/OSX/Linux
>
> Similar way is with lluv.
> lluv is binding for libuv.
> lluv.ssl adds ssl socket and lluv.websocket adds
> websocket sockets to lluv library. So there no conflicts.

I have updated the auto.build webpage with more info as this is a
recurring point. The issue should be clear now.

As for why: the alternative adds enormous complications (for everyone
really) for very little benefit.
For instance, consider what is a package manager should do in order to
update 'lzmq' if 'lzmq.timer' and 'lzmq.auth' are installed (and not
updated at the same time, as it's likely).

For the specific lzmq example: everything else being equal I will
select the FFI version over the non-FFI one.

The way I will deal with the 'add-ons' auth, pool, timer will be a
merge: the package for lzmq will contain them as well. This provided
they build, i.e. in the short term no external dependencies.

By the way the modules are always so *tiny* (a few K at most, both
code and binaries) that splitting them among multiple rocks really
seems overkill.

I fully support the principle of unified bundles, which indeed is the
direction being taken by a few projects (someone mentioned Debian
before). But I'm digressing now...

Stefano

>
>
>
>
>
>
>
>
> ---
> Это сообщение проверено на вирусы антивирусом Avast.
> https://www.avast.com/antivirus
>
>