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? Should a package own all local state files it creates in /var ? Or should it explicitly not own them so they are left behind (a bit like log files in /var/log) ?
Cheers, Jonathan.
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
"Jonathan Underwood" jonathan.underwood@gmail.com writes:
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). ... So, what is best practice?
See http://fedoraproject.org/wikiold/PackagingDrafts/Logfiles for a discussion of possible options.
Enrico
2009/1/12 Enrico Scholz enrico.scholz@informatik.tu-chemnitz.de:
"Jonathan Underwood" jonathan.underwood@gmail.com writes:
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). ... So, what is best practice?
See http://fedoraproject.org/wikiold/PackagingDrafts/Logfiles for a discussion of possible options.
Thanks, that's interesting. It could probably be extended to include state files too.
J.
Enrico
-- Fedora-packaging mailing list Fedora-packaging@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
packaging@lists.fedoraproject.org