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.
>
>Ulrich
--
Best regards,
Michał Górny (by phone)
