[Fedora-packaging] Package ownership of local state files (/var/lib)?
rc040203 at freenet.de
Mon Jan 12 13:01:23 UTC 2009
Jonathan Underwood schrieb:
> 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
* 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).
More information about the Fedora-packaging