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

[Martin Pitt]

Hey Axel, all,

thanks for raising that on the list.

Axel Beckert [2015-06-10 12:22 +0200]:
> 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.

I don't believe that package defaults should go into /etc at all
(/etc/init.d/ is a really bad idea), so this would only make it worse.

> 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.

I suggested that as a short-term local workaround in the package. I
like that better than cluttering /etc/, and it should have the same
effect.

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

Yes, absolutely. Should that become the official solution, this should
be debhelper'ed somehow.

> 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.

I'm not aware of any. However, it doesn't actually affect too many
packages: this is mostly an issue for rcS init.d scripts, which often
have very heavy (and often principally unsatisfiable) dependencies,
such as setserial in #786976. rcS scripts which depend on $remote_fs
are generally a pain (and don't work under sysvinit either if you use
/var on NFS or similar, it's just that the error is mostly hidden
there).

> 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?

Determining that for any init script is prohibitively expensive, we
can't do that in generators. I. e. we don't want to impose doing
expensive dpkg calls dozens of times on every boot. The main problem
is that init.d scripts have no declarative way of telling you which
package they belong to, so you'd need to do something like dpkg -S.
There is also no robust way to identify a "daemon path" or similar
(whose existence we could then test), as init.d scripts often don't
start daemons at all (like in this /e/i/screen-cleanup case).

The main design problem here is that removing, but not purging, a
package leaves the init.d script, and worse, leaves it enabled. (i. e.
the enabling symlinks in /etc/rc?.d/ all stay in place). That means
that such init scripts run *even* if the package they belong to is
removed.  Again, the ones starting a daemon usually test if that
daemon actually exists, for that very reason. But the ones which do
"one-shot" like stuff might not.

This isn't something which we can easily/cheaply determine and
workaround in the sysv-generator; it affects sysvinit all the same.
One option would be to "update-rc.d disable" init scripts on removal,
not purge (but then we'd lose the rc[2-5].d/ symlink structure, which
is still considered "admin config"). Or removing a package needs to
set an additional flag etc.  which signals init to not run that file.

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)