Packaging issue: .service files are no conffiles (due to /lib) while init scripts are conffiles and hence remain longer on the system upon package removal without purging

Axel Beckert abe at debian.org
Wed Jun 10 11:22:43 BST 2015


Hi,

there seem to be a general issue with how .service files should be
packaged (in /lib/systemd/system/ and not in /etc/systemd/system/):

If a package is shipping a init script as well as a service file (as
currently strongly recommend), it's usually the case that the init
script is left on the system upon package removal without also purging
its conffiles.

While this is no issue at all with sysvinit, it seems to cause issues
with systemd's sysvinit compatibility mode because the init
script is still there but the overriding .service file is already
removed. :-/

Example case where this causes ordering cycle issues:
https://bugs.launchpad.net/ubuntu/+source/screen/+bug/1462692

The bug report above contains two suggested solutions:

1) Ship the .service file in /etc/systemd/system/ instead of
   /lib/systemd/system/ so that it's removed at the same time as the
   init script and override the according lintian warning.

   Example implementation:
   https://anonscm.debian.org/cgit/collab-maint/screen.git/commit/?id=f7d8704dc

   Advantage: dead-simple and fail-safe

   Disadvantage: Overriding a lintian warning.

   Additionally, in this specific case (a symlink to /dev/null to make
   systemd ignore the init script), a file which better should not be
   changed by the local admin would be put under /etc/. Then again,
   there's not much which the local admin could change, so it
   shouldn't really hurt.

2) Don't ship the /lib/systemd/system/screen-cleanup.service link
   (possibly a less general solution) in the .deb, but create it in
   postinst and remove it in the postrm on purge.

   Advantage: No lintian warning, no file under /etc/.

   Disadvantage: Error-prone due to more complexity in the
   maintainer scripts -- which I'd like to avoid.

Is there any simpler or maybe even already supported way to solve or
avoid such issues? I'd expect that screen is not the only package
where users run into such issues.

E.g. is there a chance that systemd's sysvinit compatibility mode
ignores (wrt. dependency ordering/resolving) any init script where the
owning package is removed, but not yet purged?

I've also looked into all files in /lib/lsb/init-functions.d/ on a
desktop system running systemd as init system, but nothing in there
seems to be related to dependency resolving. Also dh_installinit(1)
currently doesn't seem to cover that topic.

P.S.: I'm not on the list, so please at least Cc me when replying.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



More information about the Pkg-systemd-maintainers mailing list