-
Nikolay Shirokovskiy authored
Now we base on some unreleased state of libunwind. This is by itself not a good practice. Yet the main motivation is that in the current version of libunwind fast path for backtrace detection on x86_64 does not work. I guess this is because of libunwind/libunwind@400b3f819ad4 (" x86_64: Stop aliasing RSP and CFA"). See libunwind/libunwind#440. Fortunately this commit is not present it the latest release. Using fast or slow path has a great impact on performance of debug build where collecting fiber gc allocation backtrace is turned on by default. It surely depends on frequency and pattern of allocation. Test sql/delete3 depends on backtrace performance most dramatically. On some installations collecting backtraces slowed down the test up to 10 times. If fast path is available then collecting backtrace does not affect performance in a noticeable way. I propose not to keep autotools products in the libunwind fork repo as it is done previously. LOG_CONFIGURE is removed because it somehow incompatible with using && in CONFIGURE_COMMAND command and not critical to the build. Also add autotools build dependencies for packpack package specs. Currently not all packpack images have autotools preinstalled so this is required for build to success. Anyway we'b better have precise build requirements in build specs. Follow-up #5665 NO_DOC=internal NO_TEST=internal NO_CHANGELOG=internal
Nikolay Shirokovskiy authoredNow we base on some unreleased state of libunwind. This is by itself not a good practice. Yet the main motivation is that in the current version of libunwind fast path for backtrace detection on x86_64 does not work. I guess this is because of libunwind/libunwind@400b3f819ad4 (" x86_64: Stop aliasing RSP and CFA"). See libunwind/libunwind#440. Fortunately this commit is not present it the latest release. Using fast or slow path has a great impact on performance of debug build where collecting fiber gc allocation backtrace is turned on by default. It surely depends on frequency and pattern of allocation. Test sql/delete3 depends on backtrace performance most dramatically. On some installations collecting backtraces slowed down the test up to 10 times. If fast path is available then collecting backtrace does not affect performance in a noticeable way. I propose not to keep autotools products in the libunwind fork repo as it is done previously. LOG_CONFIGURE is removed because it somehow incompatible with using && in CONFIGURE_COMMAND command and not critical to the build. Also add autotools build dependencies for packpack package specs. Currently not all packpack images have autotools preinstalled so this is required for build to success. Anyway we'b better have precise build requirements in build specs. Follow-up #5665 NO_DOC=internal NO_TEST=internal NO_CHANGELOG=internal
control 4.63 KiB
Source: tarantool
Priority: optional
Maintainer: Alexander Turenko <alexander.turenko@tarantool.org>
Uploaders:
Dmitry E. Oboukhov <unera@debian.org>,
PackPack <build@tarantool.org>
Build-Depends: cdbs (>= 0.4.100), debhelper (>= 9), dpkg-dev (>= 1.16.1~),
# It is recommended to use debhelper version equal to or greater than
# compatibility level. This is a workaround for Ubuntu Xenial repos
# missing debhelper 10.
base-files (<< 9.9) | debhelper (>= 10),
# Enable systemd for Debian Jessie+ and Ubuntu Wily+
debhelper (>= 9.20160709) | dh-systemd (>= 1.22) | sysvinit (<< 2.88dsf-59) | upstart (<< 1.13),
# XXX: This is a tiny hack to support Tarantool build on the old
# distributions (e.g. Ubuntu Trusty Tahr) providing CMake 3+ via
# cmake3 package that conflicts and replaces cmake package (that
# provides CMake 2.18). Alternatives resolution order allows to
# make package manager seek for cmake3 package at first and use it
# if found or fallback to cmake package (that provides CMake 3+
# for modern distributions) otherwise.
cmake3 (>= 3.3) | cmake (>= 3.3),
libreadline-dev,
libncurses5-dev,
libssl-dev,
libunwind-dev | libunwind8-dev | libunwind7-dev,
libicu-dev,
# libcurl build dependencies
zlib1g-dev,
# Install prove to run LuaJIT tests.
libtest-harness-perl,
# Install dependencies for functional tests.
python3-gevent,
python3-yaml,
# needed for datetime tests
tzdata,
# For third-party subprojects that are built with autotools.
autoconf, automake, libtool,
Section: database
Standards-Version: 4.5.1
Homepage: http://tarantool.org/
VCS-Browser: https://github.com/tarantool/tarantool
VCS-Git: git://github.com/tarantool/tarantool.git
Package: tarantool-common
Architecture: all
Priority: optional
Conflicts: tarantool-common (<< 2.2.1),
tarantool-lts-modules,
tarantool-lts-client,
tarantool-lts-postgresql-module,
tarantool-lts-mysql-module,
tarantool-dbg (<< 1.5.2),
tarantool-client (<< 1.6~),
tarantool-client-dbg (<< 1.6~),
tarantool-plugins (<< 1.6~),
tarantool-mysql-plugin (<< 1.6~),
tarantool-postgresql-plugin (<< 1.6~),
tarantool-modules,
tarantool-mysql-module,
tarantool-postgresql-module,
libtarantool-dev (<< 1.6~)
Replaces: tarantool-common (<< 2.2.1), tarantool-lts-common
Depends: ${misc:Depends}, adduser, lsb-base,
# Deps for built-in package manager
# https://github.com/tarantool/tarantool/issues/2612
openssl
Recommends: tarantool-dev, git, build-essential, cmake
Description: Tarantool in-memory database - common files
Tarantool is an in-memory database and Lua application server.
This package provides scripts to work with tarantool configuration
and log files.
Package: tarantool
Architecture: i386 amd64 armhf arm64
Priority: optional
Depends: ${shlibs:Depends}, ${misc:Depends}, netbase, libgomp1,
openssl, tarantool-common (>= 2.2.1), tzdata,
# libcurl dependencies (except ones we have already)
zlib1g
Replaces: tarantool-lts
Conflicts: tarantool-lts-modules,
tarantool-lts-postgresql-module,
tarantool-lts-mysql-module,
tarantool-lts-client,
tarantool-dbg (<< 1.5.2),
tarantool-common (<< 2.2.1),
tarantool-client (<< 1.6~),
tarantool-client-dbg (<< 1.6~),
tarantool-plugins (<< 1.6~),
tarantool-mysql-plugin (<< 1.6~),
tarantool-postgresql-plugin (<< 1.6~),
libtarantool-dev (<< 1.6~),
tarantool-modules (<< 1.6.7),
tarantool-mysql-module (<< 1.6.7),
tarantool-postgresql-module (<< 1.6.7)
Description: In-memory database with a Lua application server
Tarantool is an in-memory database and a Lua application server.
Its key properties include:
.
* flexible data model
* multiple index types: HASH, TREE, BITSET
* optional persistence and strong data durability
* log streaming replication
* Lua functions, procedures, triggers, with rich access to database API,
JSON support, inter-procedure and network communication libraries
.
This package provides Tarantool command line interpreter and server.
Package: tarantool-dev
Architecture: i386 amd64 armhf arm64
Priority: optional
Section: libdevel
Replaces: tarantool-lts-dev
Conflicts: tarantool-lts-dev,
tarantool-lts-modules,
tarantool-lts-postgresql-module,
tarantool-lts-mysql-module,
tarantool-lts-client,
tarantool-dbg (<< 1.5.2),
tarantool-common (<< 2.2.1),
tarantool-client (<< 1.6~),
tarantool-client-dbg (<< 1.6~),
tarantool-plugins (<< 1.6~),
tarantool-mysql-plugin (<< 1.6~),
tarantool-postgresql-plugin (<< 1.6~),
libtarantool-dev (<< 1.6~)
Depends: ${shlibs:Depends}, ${misc:Depends},
tarantool (= ${binary:Version})
Description: Tarantool in-memory database - development headers
Tarantool is an in-memory database and Lua application server.
This package provides server development files needed to build pluggable
modules.