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