RPM and Debian packages

[perewall]

It would be cool to have a RPM and Debian packages, like a tarantool-avro-schema or tarantool-http

When I want to build a RPM package for my application, I specify in the rpm.spec:

Requires: tarantool >= x.y.z
Requires: tarantool-module-required >= x.y.z

but using the tarantool-document I can't do this, I need to copy document.lua to my source code every time, if I want to update application's dependencies

[knazarov]

I know it may not answer your question directly, but you'd be better off installing dependent rocks with tarantoolctl rocks install. It installs dependencies into .rocks directory in the root of your app, and will work as expected when doing require('module'). You'll need to include that directory into the rpm.

rpms in tarantool repository may expire and become unavailable (and that is by design, as far as I know)

[Totktonada]

@racktear The right way to install packages is using a package manager. All other ways are for heretics.

[knazarov]

@Totktonada right, and as other high level programming languages, we have one built in. It is called luarocks. There are reasons why applications in python, ruby, javacript, perl and others mostly consume dependencies from their package managers. (software bundled with OS being notable exceptions, like yum and friends)

My primary concern with os-level packages is inability to install multiple versions of library dependencies at the same time. Well, you can, but tarantool itself doesn't have means to refer to any particular version (at least I don't know about them).

[perewall]

@racktear, my build servers on which RPM is packing, do not have access to the Internet and the way with LuaRocks does not work for me :(

I can install module to the directory with source code of my application using LuaRocks and commit/push it into the VCS, but I'm not sure if this is the right way

[Totktonada]

My primary concern with os-level packages is inability to install multiple versions of library dependencies at the same time.

@racktear The issue owner did not request this feature here. Your concern is unrelevant.

We can continue discuss 'packaging philosophy' and I have mine concerns too, but this discussion would not be relevant to the problem of the issue owner.

[knazarov]

@pwmedia I'm just saying that there is an official package manager for tarantool, and there is a way to solve your problem as you would for other programming languages - by having a local language-specific package mirror.

There is a convenient way to make rockfile distributions like this:

tarantoolctl rocks pack https://raw.githubusercontent.com/tarantool/rocks/gh-pages/document-1.0.1-1.rockspec

It will create a file called document-1.0.1-1.src.rock which you can put to any local file share and install with tarantoolctl rocks install document-1.0.1-1.src.rock.

You can choose to go with os-level packages, if you wish, but then you need to face a few problems:

1. Lack of version history on packagecloud. Seriously. Look at the packages for avro-schema. There are only packages left for 3.x, but in the rocks repository they start from version 2.x. Want to freeze your dependencies? Tough luck.

2. Many tarantool packages developed inside don't have os-level packages, and many that do haven't been updated lately. For example, tarantool-mysql. There is now Fedora 28, but the latest distro supported by the package in Fedora line is 25. This is just plain-old hard fact you can verify.

3. Many tarantool packages are not uploaded to the repositories of latest tarantool releases. For example, memcached. Last time I checked it was only present in the reporitories of tarantool 1.6 1.7 and 1.8 (while we now have 1.10 and 2.0).

4. Installing multiple packages of the same version is not supported for those tarantool packages I know of. So if developers ever need to have multiple apps on the same node, it becomes a problem off-the-shelf tarantool os-specific packages cannot solve.

Unless these problems are somehow solved, I can't endorse rpms/deps as a passable solution.

This leaves you with the following options:

• Just build your own RPMs as many organizations do
• Submit a PR which adds rpm packaging or wait for other people to do so
• Use the official package manager