1 |
On 07/09/2018 01:07 PM, Zac Medico wrote: |
2 |
> On 07/09/2018 01:00 PM, William Hubbs wrote: |
3 |
>> On Mon, Jul 09, 2018 at 08:36:33PM +0200, Ulrich Mueller wrote: |
4 |
>>>>>>>> On Mon, 9 Jul 2018, Rich Freeman wrote: |
5 |
>>> |
6 |
>>>> I'd also consider /var/cache here as well. FHS specifically suggests |
7 |
>>>> using it for web caches and the like (let's set aside the issue with |
8 |
>>>> making that global), though for the most part it is more metadata |
9 |
>>>> caching. A key principle is that it can be wiped without loss of |
10 |
>>>> data, and I think that is generally true for the repository since it |
11 |
>>>> can be synced. |
12 |
>>> |
13 |
>>> I don't think that criterium is fulfilled, because you cannot easily |
14 |
>>> restore the previous state after it's been wiped. At least not when |
15 |
>>> syncing from a rsync mirror (which may have been updated in the mean |
16 |
>>> time). |
17 |
>> |
18 |
>> The criteria for /var/cache do not require being able to restore the |
19 |
>> exact previous state; they just require that the application be able to |
20 |
>> regenerate or restore the data , so they are definitely fulfilled.[1]. |
21 |
> |
22 |
> If it's an rsync tree then we cannot restore the precise state, for |
23 |
> example you might not be able to rebuild one of your installed packages |
24 |
> if the corresponding ebuild has been removed upstream. |
25 |
|
26 |
Whoops I didn't mean to simply repeat what Ulrich said. My point is that |
27 |
the spirit of the FHS might be that "nothing is lost", but you certainly |
28 |
can lose some valuable state if it's an rsync tree. |
29 |
-- |
30 |
Thanks, |
31 |
Zac |