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]

Hi,

Michael Biebl wrote:
> Am 10.06.2015 um 13:19 schrieb Axel Beckert:
> > Michael Biebl wrote:
> >> To address this, we added code do dh_systemd,
> 
> ..
> 
> > After reading the source of
> > /usr/share/perl5/Debian/Debhelper/Sequence/systemd.pm, I assume that
> > 
> >   dh $@ --with=systemd
> > 
> > suffices.
> > 
> > Will try that.
> 
> I just noticed, that /lib/systemd/system/screen-cleanup.service isn't
> actually a service file, but a symlink to /dev/null.

Yes.

> This wasn't obvious to me from your first email.

Yes, it seemed as if that was only a special case of a more general
issue after reading the comments in LP#1462692. I didn't expect this
to make such a difference.

> So technically, you already mask the sysv init script.

Ah, that's called "masking"?

> I assume that is because you ship a tmpfiles snippet,
> /usr/lib/tmpfiles.d/screen-cleanup.conf (*) which implements the
> equivalent functionality.

Yes. Because that init script does not much more than to clean up
socket directories and set their permissions depending on the actual
permissions of the screen binary. The latter wasn't possible in all
details with systemd and was solved via an entry in debian/NEWS and
debian/README.Debian.

Background for this and some discussion are in
https://bugs.debian.org/740301

> IIRC, dh_systemd_* only operates on real service files, so won't help
> you, as this is a very specific use case.

Ok.

> So, option 2) might actually be the proper solution for your specific
> case after all. If you create that mask dynamically via postinst, this
> should be done in /etc though, I think.

I would have expected /lib according to the argumentation in your previous
mail.

> But let me first think about this more, before you go on implementing
> something.

Ok. I'll revert the previously committed solution (1) and will likely
do the next upload without a fix for LP#1462692. I want to make an
upload of some packaging-only changes soon as there is a new upstream
imminent. The fix for LP#1462692 was last thing I wanted to have in
that upload, but it seems less trivial than expected.

Anyway, thanks for caring!

> (*) you seem to ship an empty /etc/tmpfiles.d directory for no apparent
> reason

See https://sources.debian.net/src/screen/4.2.1-3/debian/README.Debian/#L104
and the following lines for the reason. Was suggested by Josh and added in
https://anonscm.debian.org/cgit/collab-maint/screen.git/commit/?id=f843000b

		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