6:26 a.m.
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.
7:01 a.m.
New subject: Package ownership of local state files (/var/lib)?
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
2:07 p.m.
"Jonathan Underwood" <jonathan.underwood(a)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
5:30 p.m.
2009/1/12 Enrico Scholz <enrico.scholz(a)informatik.tu-chemnitz.de>:
"Jonathan Underwood" <jonathan.underwood(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
5583
days inactive
5583
days old
packaging@lists.fedoraproject.org
3 comments
3 participants
participants (3)
-
Enrico Scholz -
Jonathan Underwood -
Ralf Corsepius