[Fedora-packaging] Package ownership of local state files (/var/lib)?

[Ralf Corsepius]

Jonathan Underwood schrieb:
> Hi,
>
> Firstly, apologies if this should be obvious or is documented
> somewhere and I've missed it.
>
> While in the process of updating the shorewall packages I noticed that
> on package removal directories were being left behind in
> /var/lib/shorewall because the directory contained some files created
> at run time which were not owned by the package (even though the
> directory itself is).
>
> My first thought was the obvious fix of creating these files at
> package build time (with touch) and using %ghost to own them. But then
> I decided to see what other packages do, and chose samba at random,
> figuring it's quite a mature package. With samba I see the same thing
> - files in /var/lib/samba which are unowned and so wouldn't be removed
> when removing the samba packages.
>
> So, what is best practice?
Well, a soap box answer would be: "Play it safe" ;)

>  Should a package own all local state files
> it creates in /var ?
Depends on the use-case.

In general, having everything owned is the preferred approach. The 
%ghost'ing case you mention is a subcase of this kind of situation and 
may well be suitable in certain situations.

However, due to the dynamics below /var, in some cases, other approaches 
may occasionally be more suitable there, e.g.:

* cleaning up via %post scriptlets.
E.g. suitable when wanting to remove whole directory hierarchies with 
dynamic contents.

* Not performing any cleanup.
In general, this should be avoided whenever possible, nevertheless, it 
may sometimes preferable, e.g. to allow users/admins some kind of 
"post-mortem/post-deinstallation" inspection - At least some of the 
/var/log/* cases are from this group, because these package's 
maintainers want to leave log files around, to allow admins to inspect 
them in cases something goes "utterly wrong".

>  Or should it explicitly not own them so they are
> left behind (a bit like log files in /var/log) ?
>   
Depends, again (c.f. above).

Ralf