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