1 |
Apologies if this has been addressed previously, but my searches of the |
2 |
Gentoo website, devmanual, forums, and mailing list archives didn't turn |
3 |
up anything definitive. |
4 |
|
5 |
Is there any sort of policy covering how an ebuild should deal with |
6 |
/var/cache during unmerge? |
7 |
|
8 |
The devmanual pages for pkg_prerm (http://tinyurl.com/huh7n) and |
9 |
pkg_postrm (http://tinyurl.com/f5b7o) are the closest I've come to an |
10 |
answer, but I don't consider deletion of the cache dir to be the same as |
11 |
updating it. |
12 |
|
13 |
I've looked at a few ebuilds in the tree (including samba and squid) and |
14 |
they seem to leave in place any cache files created during normal |
15 |
execution of the package in question. |
16 |
|
17 |
This means that after an unmerge the sysadmin needs to go and clean out |
18 |
/var/cache/whatever. |
19 |
|
20 |
During ebuild development and testing, I can see why one might want the |
21 |
cache files to remain, so unconditional cleaning of /var/cache is out of |
22 |
the question. However, removing of cache files could be controlled by a |
23 |
FEATURE (eg. keepcache - unless that implies the retention of cache |
24 |
files from the original merge a la keepwork and keeptemp). |
25 |
|
26 |
A similar issue exists with log files, but I'd expect them to occupy |
27 |
less space than caches, and generally be considered more useful (since |
28 |
they can't be regenerated). If they were to be dealt with, perhaps |
29 |
portage could have a purge option that removes all traces of a package |
30 |
from the system - including log and cache files (it looks like temp |
31 |
files should already be cleaned out by the ebuild). |
32 |
|
33 |
Of course, the general opinion might be that management of /var/cache is |
34 |
outside the scope of portage, and best left to the sysadmin (and/or an |
35 |
separate automated tool), although the FHS doesn't specify either way |
36 |
(http://tinyurl.com/26gpd). That's fine with me, but I think it's good |
37 |
to have this on record in the mailing list archives, and perhaps in the |
38 |
devmanual as well. |
39 |
|
40 |
Cheers |
41 |
|
42 |
Andrew |
43 |
|
44 |
-- |
45 |
gentoo-dev@g.o mailing list |