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].
> Also Portage doesn't treat it likea a cache, i.e. it doesn't start to > fetch ebuilds from remote if it doesn't find them in the local tree. There is no definition of how a cache should be treated in fhs, so I don't see this as an argument against /var/cache either. William [1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#varcacheApplicationCacheData
signature.asc
Description: Digital signature
