On Fri, Jul 27, 2018 at 1:40 AM, Michał Górny <mgo...@gentoo.org> wrote: > Dnia 27 lipca 2018 10:32:17 CEST, Ulrich Mueller <u...@gentoo.org> napisał(a): >>>>>>> On Thu, 19 Jul 2018, Chí-Thanh Christopher Nguyễn wrote: >> >>>> Users must never need to modify files in /var/lib to configure a >>>> package's operation, and _the_specific_file_hierarchy_ used to >>>> store the data _must_not_be_ _exposed_ to regular users." >> >>> One small note, while it is never needed to modify, skel.ebuild >>> would then be a file that is meant to be accessed by users in >>> /var/lib if your proposal is realized. >> >>That's one of the reasons why the proposal prefers /var/db. The other >>reason is existing usage in eselect-repository. >> >>>>>>> On Thu, 19 Jul 2018, Ulrich Mueller wrote: >> >>> In my understanding, a cache is typically an open collection of >>items. >>> Some subset of them can be deleted without much negative consequence, >>> and there may also be surplus items that are no longer necessary and >>> will be expired at some later time in order to reclaim disk space. >> >>> Nothing of this is true for an ebuild repository, which is a closed >>> collection of files: A single file cannot be discarded without >>> invalidating the whole repository. Also there cannot be any stray >>> files which would be expired later. Same as above, a single stray >>file >>> will invalidate all. >> >>> (A collection of binary packages may qualify as a cache though, by >>> this definition.) >> >>So, considering all the feedback from mailing list and IRC: >> >> /usr/portage -> /var/db/repos/gentoo >> /usr/portage/distfiles -> /var/cache{,/gentoo}/distfiles >> /usr/portage/packages -> /var/cache{,/gentoo}/binpkgs >> >>Open question: Should we have the additional "gentoo" path component >>for the ones in /var/cache? The tradeoff is between a path that is >>easier to type, or slightly easier usage if someone wants to NFS mount >>distfiles and binpkgs. > > Note that NFS is not exactly clear cut here since binpkgs are not portable to > different hosts, so you can have multiple variants of it.
True, but trivially solvable by configuring like-hosts to share packages. Skylake packages go here, Sandybridge packages go here, etc. This is what I do.