1 |
On Mon, Jul 09, 2018 at 08:36:33PM +0200, Ulrich Mueller wrote: |
2 |
> >>>>> On Mon, 9 Jul 2018, Rich Freeman wrote: |
3 |
> |
4 |
> > I'd also consider /var/cache here as well. FHS specifically suggests |
5 |
> > using it for web caches and the like (let's set aside the issue with |
6 |
> > making that global), though for the most part it is more metadata |
7 |
> > caching. A key principle is that it can be wiped without loss of |
8 |
> > data, and I think that is generally true for the repository since it |
9 |
> > can be synced. |
10 |
> |
11 |
> I don't think that criterium is fulfilled, because you cannot easily |
12 |
> restore the previous state after it's been wiped. At least not when |
13 |
> syncing from a rsync mirror (which may have been updated in the mean |
14 |
> time). |
15 |
|
16 |
The criteria for /var/cache do not require being able to restore the |
17 |
exact previous state; they just require that the application be able to |
18 |
regenerate or restore the data , so they are definitely fulfilled.[1]. |
19 |
|
20 |
> Also Portage doesn't treat it likea a cache, i.e. it doesn't start to |
21 |
> fetch ebuilds from remote if it doesn't find them in the local tree. |
22 |
|
23 |
There is no definition of how a cache should be treated in fhs, so I |
24 |
don't see this as an argument against /var/cache either. |
25 |
|
26 |
William |
27 |
|
28 |
[1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#varcacheApplicationCacheData |