Re: [gentoo-dev] rfc: moving default location of portage tree

[Richard Yao]

> On Jul 11, 2018, at 6:24 PM, Rich Freeman <rich0@g.o> wrote:
>
>> On Wed, Jul 11, 2018 at 6:11 PM Richard Yao <ryao@g.o> wrote:
>>
>> Is it a violation of the FHS? /usr is for readonly data and the portage tree is generally readonly, except when being updated. The same is true of everything else in /usr.
>>
>
> It is application metadata.  It belongs in /var.  No other packages
> write to /usr when they're doing internal updates.  Obviously you need
> a writable /usr to actually install package changes, but that
> shouldn't be necessary just to sync the repository.
>
> I was asking around and it seems like most distros stick their
> repositories in /var/lib.  I can't imagine that too many would have
> even considered sticking them in /usr.
I would consider the package manager to be special in that it is a step of the system update process, but I agree that it could be nicer to have in /var.

We have a problem using /var/lib because /var/lib/portage is already in use. I guess /var/portage is not  a terrible choice.
>
>> I am confused as to how we only now realized it was a FHS violation when it has been there for ~15 years. I was under the impression that /usr was the correct place for it.
>
> It has certainly been pointed out in the past.  Nothing was changed
> for the same reason that nothing will probably be changed this time -
> people don't like change and the people who know better just slowly
> patch around Gentoo's oddities.  Somebody was just posting a manifesto
> about deploying more experimental technologies, and here we can't move
> a repository out of /usr.
>
> And if nothing else, can we at least move /usr/portage/distfiles
> someplace else?  Surely you have to agree that this doesn't belong in
> usr, or nested in the middle of a repository?
Well, if it is changed during system updates, then the same logic applies, but quite honestly, I never liked having the distfiles or packages directories there. You can have unnecessary headaches when mounting inside a mount point other than /.
>
> --
> Rich
>