Inappropriate dependency in deb package

[rosik]

Tarantool version: 2.4.2

$ apt show tarantool tarantool-common                                                                                                                                                   
Package: tarantool 
Version: 2.4.2.0.gcccd89701-1
Depends: ..., tarantool-common (>= 1.7.5.46)

Tarantool dependency on tarantool-common from is specified as >= 1.7.5, while it should be == 2.4.2....

The tarantoolctl binary belongs to the tarantool-common package, but all luarocks modules - to the tarantool. Version inconsistency causes problems.

[Totktonada]

The idea of tarantool-common and this weak dependency is to don't update init/service files (and restart the daemon) each time tarantool is updated. AFAIK, it is Debian policy to restart a service at update. AFAIR, we can skip restart by using DEB_DH_SYSTEMD* options. Maybe there were no such ability in the past or the idea was to restart tarantool anyway when the entire system is upgraded (and so tarantool-common is updated too).

In short: the weak dependency is right, but the minimal dependency should be bumped when given tarantoolctl version is not compatible with given tarantool version anymore.

[Totktonada]

The problem per se (reported by a user via @rosik to us):

/usr/bin/tarantoolctl:908: module 'luarocks.cfg' not found

So, we should depend on tarantool-common with tarantoolctl with luarocks-3 support for versions of tarantool, which ship luarocks-3.

[Mons]

Maybe better change shipment unit of luarocks module and move it to tarantoolctl package (common)?

[rosik]

I would also add that tarantoolctl --help reported 2.4.2, while in fact it was installed from 1.10 package, and it's misleading.

[Totktonada]

Maybe better change shipment unit of luarocks module and move it to tarantoolctl package (common)?

Seems good on the first glance.

NB: If we'll do, we should correctly set which packages blocks each others to avoid conflicting by files.

[rosik]

The same issue just affected @Errora

The reason is the old tarantool-common 1.9, apt upgrade fixed it.

[DifferentialOrange]

The idea of tarantool-common and this weak dependency is to don't update init/service files (and restart the daemon) each time tarantool is updated. AFAIK, it is Debian policy to restart a service at update. AFAIR, we can skip restart by using DEB_DH_SYSTEMD* options. Maybe there were no such ability in the past or the idea was to restart tarantool anyway when the entire system is upgraded (and so tarantool-common is updated too).

In short: the weak dependency is right, but the minimal dependency should be bumped when given tarantoolctl version is not compatible with given tarantool version anymore.

AFAIK, current deb packages skips restart so this weak dependency is not required anymore

tarantool/debian/rules

Line 27 in 60f1681

DEB_DH_SYSTEMD_START_ARGS_tarantool-common := --no-restart-on-upgrade tarantool.service

[Totktonada]

Seems so. #6400 is about that. We want to resolve current problems first, provide updates to Debian's repositories (simple update will not require much attention from Debian developers) and only after this rearrange the packages and propose the new packages structure to review into Debian.

[DifferentialOrange]

Issue reproducer

Test container

docker run --name debian_bash --rm -i -t debian:buster bash

Install

apt-get update
apt-get install -y curl
curl -L https://tarantool.io/OtKysgx/release/2.8/installer.sh | bash
apt-get install -y tarantool-common=1.9.1.26.g63eb81e3c-1.1

apt-get install -y tarantool=2.8.2.0.gfc96d10f5-1
tarantool is already the newest version (2.8.2.0.gfc96d10f5-1).

Info

tarantool

Tarantool 2.8.2-0-gfc96d10f5
type 'help' for interactive help

apt-cache policy tarantool

tarantool:
  Installed: 2.8.2.0.gfc96d10f5-1
  Candidate: 2.8.2.0.gfc96d10f5-1
  Version table:
 *** 2.8.2.0.gfc96d10f5-1 1001
        500 https://download.tarantool.org/OtKysgx/tarantool/release/2.8/debian buster/main amd64 Packages
        100 /var/lib/dpkg/status
     2.8.1.0.ge2a1ec0c2-1 1001
        500 https://download.tarantool.org/OtKysgx/tarantool/release/2.8/debian buster/main amd64 Packages
     2.8.0.0.gefc30ccf8-1 1001
        500 https://download.tarantool.org/OtKysgx/tarantool/release/2.8/debian buster/main amd64 Packages
     1.9.1.26.g63eb81e3c-1.1 500
        500 http://deb.debian.org/debian buster/main amd64 Packages

apt-cache policy tarantool-common

tarantool-common:
  Installed: 1.9.1.26.g63eb81e3c-1.1
  Candidate: 2.8.2.0.gfc96d10f5-1
  Version table:
     2.8.2.0.gfc96d10f5-1 500
        500 https://download.tarantool.org/OtKysgx/tarantool/release/2.8/debian buster/main amd64 Packages
     2.8.1.0.ge2a1ec0c2-1 500
        500 https://download.tarantool.org/OtKysgx/tarantool/release/2.8/debian buster/main amd64 Packages
 *** 1.9.1.26.g63eb81e3c-1.1 500
        500 http://deb.debian.org/debian buster/main amd64 Packages
        100 /var/lib/dpkg/status

How to broke

tarantoolctl rocks install luacheck

LuajitError: /usr/bin/tarantoolctl:863: module 'luarocks.cfg' not found:
	no field package.preload['luarocks.cfg']
	no file '/luarocks/cfg.lua'
	no file '/luarocks/cfg/init.lua'
	no file '/luarocks/cfg.so'
	no file '/.rocks/share/tarantool/luarocks/cfg.lua'
	no file '/.rocks/share/tarantool/luarocks/cfg/init.lua'
	no file '/.rocks/lib/tarantool/luarocks/cfg.so'
	no file '/root/.luarocks/share/lua/5.1/luarocks/cfg.lua'
	no file '/root/.luarocks/share/lua/5.1/luarocks/cfg/init.lua'
	no file '/root/.luarocks/share/lua/lua
fatal error, exiting the event loop

[Totktonada]

This problem was fixed in tarantool 2.10.0.

Package	Requires	Conflicts
tarantool-2.10.0	tarantool-common >= 2.2.1	tarantool-common (<< 2.2.1)1
tarantool-common-2.10.0		tarantool-common (<< 2.2.1)
tarantool-dev-2.10.0	tarantool (exactly same version)	tarantool-common (<< 2.2.1)

That's correct: tarantool-2.10.0, which expects luarocks 3, requires tarantool-common that contains luarocks 3 and conflicts with one that contains luarocks 2.

Let's look on latest 1.10 release:

Package	Requires	Conflicts
tarantool-1.10.14	tarantool-common >= 1.7.5.46	tarantool-common (<< 1.6~)
tarantool-common-1.10.14		tarantool-common (<< 1.6~)
tarantool-dev-1.10.14	tarantool (exactly same version)	tarantool-common (<< 1.6~)

tarantool-1.10.14 requires tarantool-common, but it doesn't specify, whether it needs one with luarocks 2 (tarantool-common << 2.2.1) or one with luarocks 3 (tarantool-common >= 2.2.1). So both combinations are allowed.

It hits users on Debian Bullseye (11) and Ubuntu Jammy (22.04), because it contains tarantool{,-common,-dev}-2.6.0. For example: tarantool/setup-tarantool#36 (starting from words 'tarantoolctl fatal error'). Previous Debian version (Debian Buster, 10) and previous LTS Ubuntu version (Ubuntu Focal, 20.04) offer tarantool 1.9, so there is no 1.10/2.* conflict (unless a user setups two tarantool.org repositories on its own).

Our installer.sh script has some protection against such problems, see tarantool/installer.sh#11 (package origin pinning). But the script is not the only installation method, so on the first glance it looks meaningful to update the control file for tarantool 1.10.

However I don't know, to be honest, whether the fix would actually make users more happy. I guess that without pinning of the installer.sh kind, the packages will anyway updated to 2.6.0 at next apt-get upgrade. So 1.10 user likely pins it on Debian Bullseye/Ubuntu Jammy. But if all the three packages are pinned, the user shouldn't meet the problem.

(In assumption that pinning of the origin will likely solve all the problems transparently for a user, I filed tarantool/doc#3252.)

It is one more confirmation of #6400's point: the separate tarantool-common is error prone.

Footnotes

1. Strictly less than 2.2.1. ↩