Unable to install tarantool-dev on Debian Bullseye #10
Labels
bug
Something isn't working
Comments
Totktonada
added a commit
to tarantool/smtp
that referenced
this issue
Sep 23, 2021
There are distributions, where tarantool is in base repositories (such as Fedora 30-34 or Ubuntu Focal). There are ones, where it is in semi-official repos such as EPEL (CentOS 7/8). There are ones, where we have no tarantool package at all (or have only old tarantool-lts as in Ubuntu Bionic). It seems meaningful to enable the tarantool repository everywhere and don't depend on presence of a tarantool package in distribution base repositories. The repository is enabled using the installer.sh script: see [1] for details. Aside of just enabling the repo it configures a package manager (apt-get/yum/dnf) to prefer a package from our repository even when it has lower version. So we'll build against latest 1.10 on all distributions, it looks as the good side effect: unification. Worked around a problem with pinned tarantool package and unpinned tarantool-dev, see [2]. [1]: https://github.com/tarantool/installer.sh [2]: tarantool/installer.sh#10 Part of #34 Co-authored-by: Alexander Turenko <[email protected]>
|
I was hitted by this on Debian Bullseye and worked around in tarantool/smtp#42 for myself. |
Totktonada
added a commit
to tarantool/smtp
that referenced
this issue
Sep 24, 2021
There are distributions, where tarantool is in base repositories (such as Fedora 30-34 or Ubuntu Focal). There are ones, where it is in semi-official repos such as EPEL (CentOS 7/8). There are ones, where we have no tarantool package at all (or have only old tarantool-lts as in Ubuntu Bionic). It seems meaningful to enable the tarantool repository everywhere and don't depend on presence of a tarantool package in distribution base repositories. The repository is enabled using the installer.sh script: see [1] for details. Aside of just enabling the repo it configures a package manager (apt-get/yum/dnf) to prefer a package from our repository even when it has lower version. So we'll build against latest 1.10 on all distributions, it looks as the good side effect: unification. Worked around a problem with pinned tarantool package and unpinned tarantool-dev, see [2]. [1]: https://github.com/tarantool/installer.sh [2]: tarantool/installer.sh#10 Part of #34 Co-authored-by: Alexander Turenko <[email protected]>
|
Found another case: tarantool-common should be pinned too. $ docker run -it debian:bullseye
(docker) $ apt-get update
(docker) $ apt-get install -y curl
(docker) $ curl -LsSf https://www.tarantool.io/release/1.10/installer.sh | bash
(docker) $ echo -e "\nPackage: tarantool-dev\nPin: origin download.tarantool.org\nPin-Priority: 1001" >> /etc/apt/preferences.d/tarantool
(docker) $ apt-get install -y tarantool
(docker) $ tarantoolctl rocks list
LuajitError: /usr/bin/tarantoolctl:923: module 'luarocks.core.cfg' not found:
no field package.preload['luarocks.core.cfg']
no file './luarocks/core/cfg.lua'
no file './luarocks/core/cfg/init.lua'
no file './luarocks/core/cfg.so'
no file '//.rocks/share/tarantool/luarocks/core/cfg.lua'
no file '//.rocks/share/tarantool/luarocks/core/cfg/init.lua'
no file '/.rocks/share/tarantool/luarocks/core/cfg.lua'
no file '/.rocks/share/tarantool/luarocks/core/cfg/init.lua'
no file '//.rocks/lib/tarantool/luarocks/core/cfg
fatal error, exiting the event loop
(docker) $ dpkg -l | grep tarantool
ii tarantool 1.10.11.0.gf0b0e7ecf-1 amd64 In-memory database with a Lua application server
ii tarantool-common 2.6.0-1 all Tarantool in-memory database - common files
ii tarantool-dev 1.10.11.0.gf0b0e7ecf-1 amd64 Tarantool in-memory database - development headersapt-get allows to install inappropriate tarantool-common dependency due to tarantool/tarantool#5429. I guess after fix of this tarantool's issue we'll get something like the 'unmet dependencies' problem above. |
Totktonada
added a commit
that referenced
this issue
Sep 27, 2021
The situation occurs on Debian Bullseye (where tarantool-2.6 is in the base repositories), when we enable our repository for tarantool-1.10. The installer.sh script pins tarantool package from our repository. But we should pin tarantool-dev package too, otherwise apt-get will unable to install it: | $ apt-get install -y tarantool-dev | <...> | The following packages have unmet dependencies: | tarantool-dev : Depends: tarantool (= 2.6.0-1) but | 1.10.11.0.gf0b0e7ecf-1 is to be installed | E: Unable to correct problems, you have held broken pack We should also pin tarantool-common, otherwise apt-get will install incorrect version of the package: | $ apt-get install -y tarantool | <...> | $ dpkg -l | grep tarantool | ii tarantool 1.10.11.0.gf0b0e7ecf-1 amd64 <...> | ii tarantool-common 2.6.0-1 all <...> | ii tarantool-dev 1.10.11.0.gf0b0e7ecf-1 amd64 <...> `tarantoolctl rocks` will not work with those tarantool and tarantool-common versions, see tarantool/tarantool#5429. Fixes #10
ylobankov
pushed a commit
that referenced
this issue
Nov 16, 2021
The situation occurs on Debian Bullseye (where tarantool-2.6 is in the base repositories), when we enable our repository for tarantool-1.10. The installer.sh script pins tarantool package from our repository. But we should pin tarantool-dev package too, otherwise apt-get will unable to install it: | $ apt-get install -y tarantool-dev | <...> | The following packages have unmet dependencies: | tarantool-dev : Depends: tarantool (= 2.6.0-1) but | 1.10.11.0.gf0b0e7ecf-1 is to be installed | E: Unable to correct problems, you have held broken pack We should also pin tarantool-common, otherwise apt-get will install incorrect version of the package: | $ apt-get install -y tarantool | <...> | $ dpkg -l | grep tarantool | ii tarantool 1.10.11.0.gf0b0e7ecf-1 amd64 <...> | ii tarantool-common 2.6.0-1 all <...> | ii tarantool-dev 1.10.11.0.gf0b0e7ecf-1 amd64 <...> `tarantoolctl rocks` will not work with those tarantool and tarantool-common versions, see tarantool/tarantool#5429. Fixes #10
LeonidVas
added a commit
to tarantool/tarantool-c
that referenced
this issue
Jun 2, 2022
There are distributions, where tarantool is in base repositories (such as Fedora 30-34 or Ubuntu Focal). There are ones, where it is in semi-official repos such as EPEL (CentOS 7/8). There are ones, where we have no tarantool package at all (or have only old tarantool-lts as in Ubuntu Bionic). It seems meaningful to enable the tarantool repository everywhere and don't depend on presence of a tarantool package in distribution base repositories. The repository is enabled using the installer.sh script: see [1] for details. Aside of just enabling the repo it configures a package manager (apt-get/yum/dnf) to prefer a package from our repository even when it has lower version. So we'll build against latest 1.10 on all distributions, it looks as the good side effect: unification. Worked around a problem with pinned tarantool package and unpinned tarantool-dev, see [2]. [1]: https://github.com/tarantool/installer.sh [2]: tarantool/installer.sh#10 Co-authored-by: Alexander Turenko <[email protected]>
LeonidVas
added a commit
to tarantool/queue
that referenced
this issue
Jun 2, 2022
There are distributions, where tarantool is in base repositories (such as Fedora 30-34 or Ubuntu Focal). There are ones, where it is in semi-official repos such as EPEL (CentOS 7/8). There are ones, where we have no tarantool package at all (or have only old tarantool-lts as in Ubuntu Bionic). It seems meaningful to enable the tarantool repository everywhere and don't depend on presence of a tarantool package in distribution base repositories. The repository is enabled using the installer.sh script: see [1] for details. Aside of just enabling the repo it configures a package manager (apt-get/yum/dnf) to prefer a package from our repository even when it has lower version. So we'll build against latest 1.10 on all distributions, it looks as the good side effect: unification. Worked around a problem with pinned tarantool package and unpinned tarantool-dev, see [2]. [1]: https://github.com/tarantool/installer.sh [2]: tarantool/installer.sh#10 Co-authored-by: Alexander Turenko <[email protected]>
LeonidVas
added a commit
to tarantool/queue
that referenced
this issue
Jun 6, 2022
There are distributions, where tarantool is in base repositories (such as Fedora 30-34 or Ubuntu Focal). There are ones, where it is in semi-official repos such as EPEL (CentOS 7/8). There are ones, where we have no tarantool package at all (or have only old tarantool-lts as in Ubuntu Bionic). It seems meaningful to enable the tarantool repository everywhere and don't depend on presence of a tarantool package in distribution base repositories. The repository is enabled using the installer.sh script: see [1] for details. Aside of just enabling the repo it configures a package manager (apt-get/yum/dnf) to prefer a package from our repository even when it has lower version. So we'll build against latest 1.10 on all distributions, it looks as the good side effect: unification. Worked around a problem with pinned tarantool package and unpinned tarantool-dev, see [2]. [1]: https://github.com/tarantool/installer.sh [2]: tarantool/installer.sh#10 Co-authored-by: Alexander Turenko <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It is due to the following preferences file:
installer.sh/static/installer.sh
Lines 246 to 247 in 8cc2608
If we'll add tarantool-dev package with the same origin and priority, the problem will gone.
The text was updated successfully, but these errors were encountered: