Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)

[Ulrich Mueller]

>>>>> 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.

Ulrich