Your message dated Sat, 26 Apr 2014 19:49:48 +0200
with message-id <[email protected]>
and subject line Re: Bug#717603: Acknowledgement (How to handle service files,
where [Install] has changed)
has caused the Debian Bug report #717769,
regarding Handle Alias= lines for disabled service files
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
717769: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717769
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dh-systemd
Version: 1.7
Severity: normal
Atm, we run deb-systemd-helper enable only during the initial
installation of the package (to preserve modifications of the
administrator).
That means, if the [Install] section of a package changes, we don't not
update the symlinks accordingly, which might lead to non-functional
services.
As an example, the latest bluetooth.service file now has
Alias=dbus-org.bluez.service
i.e., the D-Bus activation only works if that symlink is created and the
package would fail after the upgrade.
In a way, that is similar to SysV init scripts, where the LSB header has
changed. The current practice afaicr is, to remove all symlinks via
update-rc.d remove and let update-rc.d defaults re-create the new
symlinks.
A similar solution could be, that we check in pre-inst, if the package
is enabled, remove the symlinks via deb-systemd-helper disable, and let
deb-systemd-helper enable re-create the symlinks in postinst.
I'm not sure, if that covers all possible cases, so we'd have to be
careful when removing the symlinks.
This doesn't necessarily have to be in dh-systemd itself.
We can require that maintainers need to add that code to the maintainer
scripts themselves as part of the upgrade process.
We should have tested example code though and relevant documentation in
either the Systemd/Packaging wiki or the dh-systemd man page (or both).
I'm not sure if we can automatically detect this situation in i-s-h
itself, for that we'd have to keep a copy of the complete .service file
(well, at least of the [Install] section).
Michael
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.10-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages dh-systemd depends on:
ii debhelper 9.20130630
ii perl 5.14.2-21
dh-systemd recommends no packages.
dh-systemd suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Hi Michael,
As discussed in person, let’s close this bug.
We are not using Alias= any more but are instead recommending to use
symlinks. Those have the proper behavior already and are a cleaner
solution than special-casing Alias in our transition tooling.
--
Best regards,
Michael
--- End Message ---
