MirrorHub/synapse
0
0
Fork 1
mirror of https://mau.dev/maunium/synapse.git synced 2024-12-21 07:24:06 +01:00
Code Issues Projects Releases Wiki Activity
synapse/debian/control

49 lines
1.4 KiB
Text
Raw Normal View History

Debian packaging via dh_virtualenv (#4285)
2018-12-20 12:33:29 +01:00
Source: matrix-synapse-py3
Section: contrib/python
Priority: extra
Maintainer: Synapse Packaging team <packages@matrix.org>
Improve `Depends` specs in debian package. (#5675) This is basically a contrived way of adding a `Recommends` on `libpq5`, to fix #5653. The way this is supposed to happen in debhelper is to run `dh_shlibdeps`, which in turn runs `dpkg-shlibdeps`, which spits things out into `debian/<package>.substvars` whence they can later be included by `control`. Previously, we had disabled `dh_shlibdeps`, mostly because `dpkg-shlibdeps` gets confused about PIL's interdependent objects, but that's not really the right thing to do and there is another way to work around that. Since we don't always use postgres, we don't necessarily want a hard Depends on libpq5, so I've actually ended up adding an explicit invocation of `dpkg-shlibdeps` for `psycopg2`. I've also updated the build-depends list for the package, which was missing a couple of entries.
2019-07-17 18:47:07 +02:00
# keep this list in sync with the build dependencies in docker/Dockerfile-dhvirtualenv.
Fix failures in Debian packaging (#9079) Debian package builds were failing for two reasons: 1. Python versions prior to 3.7 throw exceptions when attempting to print Unicode characters under a "C" locale. (#9076) 2. We depended on `dh-systemd` which no longer exists in Debian Bullseye, but is necessary in Ubuntu Xenial. (#9073) Setting `LANG="C.UTF-8"` in the build environment fixes the first issue. See also: https://bugs.python.org/issue19846 The second issue is a bit trickier. The dh-systemd package was merged into debhelper version 9.20160709 and a transitional package left in its wake. The transitional dh-systemd package was removed in Debian Bullseye. However, Ubuntu Xenial ships an older debhelper, and still needs dh-systemd. Thus, builds were failing on Bullseye since we depended on a package which had ceased existing, but we couldn't remove it from the debian/control file and our build scripts because we still needed it for Ubuntu Xenial. We can fix the debian/control issue by listing dh-systemd as an alternative to the newer versions of debhelper. Since dh-systemd declares that it depends on debhelper, Ubuntu Xenial will select its older dh-systemd which will in turn pull in its older debhelper, resulting in no change from the status quo. All other supported releases will satisfy the debhelper dependency constraint and skip the dh-systemd alternative. Build scripts were fixed by unconditionally attempting to install dh-systemd on all releases and suppressing failures. Once we drop support for Ubuntu Xenial, we can revert most of this commit and rely on the version constraint on debhelper in debian/control. Fixes #9076 Fixes #9073 Signed-off-by: Dan Callahan <danc@element.io>
2021-01-12 15:15:04 +01:00
# TODO: Remove the dependency on dh-systemd after dropping support for Ubuntu xenial
# On all other supported releases, it's merely a transitional package which
# does nothing but depends on debhelper (> 9.20160709)
import from package-debian-synapse
2018-12-10 18:14:34 +01:00
Build-Depends:
Fix failures in Debian packaging (#9079) Debian package builds were failing for two reasons: 1. Python versions prior to 3.7 throw exceptions when attempting to print Unicode characters under a "C" locale. (#9076) 2. We depended on `dh-systemd` which no longer exists in Debian Bullseye, but is necessary in Ubuntu Xenial. (#9073) Setting `LANG="C.UTF-8"` in the build environment fixes the first issue. See also: https://bugs.python.org/issue19846 The second issue is a bit trickier. The dh-systemd package was merged into debhelper version 9.20160709 and a transitional package left in its wake. The transitional dh-systemd package was removed in Debian Bullseye. However, Ubuntu Xenial ships an older debhelper, and still needs dh-systemd. Thus, builds were failing on Bullseye since we depended on a package which had ceased existing, but we couldn't remove it from the debian/control file and our build scripts because we still needed it for Ubuntu Xenial. We can fix the debian/control issue by listing dh-systemd as an alternative to the newer versions of debhelper. Since dh-systemd declares that it depends on debhelper, Ubuntu Xenial will select its older dh-systemd which will in turn pull in its older debhelper, resulting in no change from the status quo. All other supported releases will satisfy the debhelper dependency constraint and skip the dh-systemd alternative. Build scripts were fixed by unconditionally attempting to install dh-systemd on all releases and suppressing failures. Once we drop support for Ubuntu Xenial, we can revert most of this commit and rely on the version constraint on debhelper in debian/control. Fixes #9076 Fixes #9073 Signed-off-by: Dan Callahan <danc@element.io>
2021-01-12 15:15:04 +01:00
debhelper (>= 9.20160709) | dh-systemd,
Install the optional dependencies into the debian package (#4325) since #4298, the optional dependencies are no longer installed with a simple `pip install .`, which meant that they were not being included in the debian package. The easy fix to that is dh_virtualenv --extras, but that needs dh_virtualenv 1.1...
2019-01-02 08:17:39 +01:00
dh-virtualenv (>= 1.1),
Improve `Depends` specs in debian package. (#5675) This is basically a contrived way of adding a `Recommends` on `libpq5`, to fix #5653. The way this is supposed to happen in debhelper is to run `dh_shlibdeps`, which in turn runs `dpkg-shlibdeps`, which spits things out into `debian/<package>.substvars` whence they can later be included by `control`. Previously, we had disabled `dh_shlibdeps`, mostly because `dpkg-shlibdeps` gets confused about PIL's interdependent objects, but that's not really the right thing to do and there is another way to work around that. Since we don't always use postgres, we don't necessarily want a hard Depends on libpq5, so I've actually ended up adding an explicit invocation of `dpkg-shlibdeps` for `psycopg2`. I've also updated the build-depends list for the package, which was missing a couple of entries.
2019-07-17 18:47:07 +02:00
libsystemd-dev,
libpq-dev,
Debian packaging via dh_virtualenv (#4285)
2018-12-20 12:33:29 +01:00
lsb-release,
python3-dev,
python3,
python3-setuptools,
python3-pip,
python3-venv,
tar,
Update debian Conflicts specifications (#4349) ... to allow installation alongside our matrix-synapse transitional package.
2019-01-04 18:24:13 +01:00
Standards-Version: 3.9.8
Debian packaging via dh_virtualenv (#4285)
2018-12-20 12:33:29 +01:00
Homepage: https://github.com/matrix-org/synapse
import from package-debian-synapse
2018-12-10 18:14:34 +01:00
Debian packaging via dh_virtualenv (#4285)
2018-12-20 12:33:29 +01:00
Package: matrix-synapse-py3
Architecture: amd64
Update debian Conflicts specifications (#4349) ... to allow installation alongside our matrix-synapse transitional package.
2019-01-04 18:24:13 +01:00
Provides: matrix-synapse
s/Breaks/Conflicts/ in debian/control Otherwise people can't upgrade from matrix-synapse without removing it first
2019-01-11 18:05:45 +01:00
Conflicts:
matrix-synapse (<< 0.34.0.1-0matrix2),
matrix-synapse (>= 0.34.0.1-1),
Debian packaging via dh_virtualenv (#4285)
2018-12-20 12:33:29 +01:00
Pre-Depends: dpkg (>= 1.16.1)
import from package-debian-synapse
2018-12-10 18:14:34 +01:00
Depends:
adduser,
debconf,
Debian packaging via dh_virtualenv (#4285)
2018-12-20 12:33:29 +01:00
python3-distutils|libpython3-stdlib (<< 3.6),
${misc:Depends},
Improve `Depends` specs in debian package. (#5675) This is basically a contrived way of adding a `Recommends` on `libpq5`, to fix #5653. The way this is supposed to happen in debhelper is to run `dh_shlibdeps`, which in turn runs `dpkg-shlibdeps`, which spits things out into `debian/<package>.substvars` whence they can later be included by `control`. Previously, we had disabled `dh_shlibdeps`, mostly because `dpkg-shlibdeps` gets confused about PIL's interdependent objects, but that's not really the right thing to do and there is another way to work around that. Since we don't always use postgres, we don't necessarily want a hard Depends on libpq5, so I've actually ended up adding an explicit invocation of `dpkg-shlibdeps` for `psycopg2`. I've also updated the build-depends list for the package, which was missing a couple of entries.
2019-07-17 18:47:07 +02:00
${shlibs:Depends},
debian package: symlink to python-3.X (#4433) In the debian package, make the virtualenv symlink python to /usr/bin/python3.X rather than /usr/bin/python3. Also make sure we depend on the right python3.x package. This might help a bit with subtle failures when people install a package from the wrong distro (https://github.com/matrix-org/synapse/issues/4431).
2019-01-23 12:43:04 +01:00
${synapse:pydepends},
Debian packaging via dh_virtualenv (#4285)
2018-12-20 12:33:29 +01:00
# some of our scripts use perl, but none of them are important,
# so we put perl:Depends in Suggests rather than Depends.
Improve `Depends` specs in debian package. (#5675) This is basically a contrived way of adding a `Recommends` on `libpq5`, to fix #5653. The way this is supposed to happen in debhelper is to run `dh_shlibdeps`, which in turn runs `dpkg-shlibdeps`, which spits things out into `debian/<package>.substvars` whence they can later be included by `control`. Previously, we had disabled `dh_shlibdeps`, mostly because `dpkg-shlibdeps` gets confused about PIL's interdependent objects, but that's not really the right thing to do and there is another way to work around that. Since we don't always use postgres, we don't necessarily want a hard Depends on libpq5, so I've actually ended up adding an explicit invocation of `dpkg-shlibdeps` for `psycopg2`. I've also updated the build-depends list for the package, which was missing a couple of entries.
2019-07-17 18:47:07 +02:00
Recommends:
${shlibs1:Recommends},
import from package-debian-synapse
2018-12-10 18:14:34 +01:00
Suggests:
Debian packaging via dh_virtualenv (#4285)
2018-12-20 12:33:29 +01:00
sqlite3,
${perl:Depends},
import from package-debian-synapse
2018-12-10 18:14:34 +01:00
Description: Open federated Instant Messaging and VoIP server
Matrix is an ambitious new ecosystem for open federated Instant
Messaging and VoIP. Synapse is a reference Matrix server
implementation.
Reference in a new issue Copy permalink