[pkg-bacula-devel] systemd tmpfiles

[Sven Hartge]

On 18.07.2016 10:02, Carsten Leonhardt wrote:
> Hi Sven,
> 
>>> After bisecting the upstream git, I see that the file got lost in the
>>> backport from Bacula Enterprise in commit
>>> 4d2b94fa3e8018d1a462756ad6e1df7e12a29d20 from 2015-08-12.
> 
> you're right, at one time lintian complained about the wrong location of
> the tmpfile, then moved it. Later the file disappeared and I removed the
> code to install it. I didn't know what it's good for (and it probably
> wasn't as there was no native systemd support anyway?).

The upstream init scripts don't create /var/run/bacula, so
tmpfiles.d/bacula.conf is needed there as well.

The Debian init scripts contain code to create /var/run/bacula on
startup, this is why the removal of the file had not ill consequences.

> 
>> I added a patch readding the file and reenabling it in configure.in.
>>
>> Now we need to deal with leftover /etc/tmpfiles.d/bacula.conf files.
>> Just unconditionally deleting them via one of the pre/post scripts seems
>> wrong, because the admin may have customized it.
>> Maybe checking if it is the same as the one in /usr/lib/tmpfiles.d and
>> only removing the wrong one if they match and otherwise print a warning?
> 
> The file in /usr is not supposed to be changed. If someone, for some
> obscure reason, wants to customize it, is there a special location to
> drop an override file or something like that? Maybe we could move the
> file from /etc to that location then, if it differs from the default?

Moving the file would be no good, as it then differs from the file in
the package, triggering all of checksum errors, for example with debsums
and would be overwritten by the one from the package at the next package
upgrade nontheless.

The correct way for an admin to override a file in /usr/lib/tmpfiles.d
is to drop a file with the same name into /etc/tmpfiles.d

An existing /etc/tmpfiles.d/bacula.conf would do no harm (unless it has
been modified in a wrong way, for example not containing the PIDdir).

May suggestion is:

a) if the file is present and the same as the one in /usr/lib, remove it.
b) if it has been altered, keep it, maybe print a warning.

Grüße,
Sven.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-bacula-devel/attachments/20160718/63336196/attachment.sig>