On 19/01/17 23:46, Ferenc Wágner wrote: > I couldn't reproduce this on a real jessie system, only in a piuparts > chroot. I think the reason is that piuparts removes init-system-helpers > (the home of deb-systemd-helper) before the shibboleth-sp2-utils postrm > could instruct it to clean up. I'm not sure what we could do about > this.
Indeed piuparts does remove init-system-helpers before shibboleth-sp2-utils. I hadn't noticed before but it's in the log: > 0m33.9s DEBUG: Command ok: ['chroot', '/tmp/tmpH_vjLg', 'dpkg', '--purge', > 'libxerces-c3.1:amd64', 'libcurl4-openssl-dev:amd64', 'libshibsp-dev:amd64', > 'librtmp1:amd64', 'libgssapi-krb5-2:amd64', 'libssh2-1:amd64', > 'libxml-security-c17:amd64', 'libaprutil1:amd64', 'libk5crypto3:amd64', > 'libfcgi0ldbl', 'libxml-security-c-dev:amd64', 'libkeyutils1:amd64', > 'zlib1g-dev:amd64', 'libshibsp-plugins:amd64', 'init-system-helpers', > 'libaprutil1-dbd-sqlite3:amd64', 'libapr1:amd64', 'libicu-dev:amd64', > 'libldap-2.4-2:amd64', 'liblog4shib1:amd64', 'libxmltooling-dev:amd64', > 'libssl1.0.0:amd64', 'libnettle4:amd64', 'icu-devtools', 'liblua5.1-0:amd64', > 'libssl-dev:amd64', 'libtasn1-6:amd64', 'libxmltooling7:amd64', > 'libkrb5-3:amd64', 'libsasl2-modules-db:amd64', 'libexpat1:amd64', > 'libltdl7:amd64', 'libsaml9:amd64', 'libaprutil1-ldap:amd64', > 'libodbc1:amd64', 'libicu52:amd64', 'libxml2:amd64', 'libidn11:amd64', > 'apache2-bin', 'libsaml2-dev:amd64', 'liblog4shib-dev', 'libshibsp7:amd64', > 'libmemcached11:amd64', 'libffi6:amd64', 'libgnutls-deb0-28:amd64', > 'libcurl3:amd64', 'libkrb5support0:amd64', 'opensaml2-schemas', > 'libsasl2-2:amd64', 'libxerces-c-dev', 'xmltooling-schemas', > 'libhogweed2:amd64', 'libp11-kit0:amd64'] > 0m33.9s DEBUG: Starting command: ['chroot', '/tmp/tmpH_vjLg', 'dpkg', > '--purge', 'libshibsp-doc', 'shibboleth-sp2-common', 'shibboleth-sp2-utils', > 'libapache2-mod-shib2'] Why would puiparts do it in this order? shibboleth-sp2-utils depends on init-system-helpers! >> So I bumped the build-dep up a bit to: dh-systemd (>= 9.20160709). > > Why? I mean, where did this version number come from? The version comes from debhelper's changelog in jessie-backports [1]. It's when dh-systemd was moved to debhelper. Since adding this version constraint was motivated by piuparts's report, it may not be necessary in the end... Etienne [1] http://metadata.ftp-master.debian.org/changelogs/main/d/debhelper/debhelper_10.2.2~bpo8+1_changelog
signature.asc
Description: OpenPGP digital signature
