> On Jul 11, 2018, at 6:24 PM, Rich Freeman <ri...@gentoo.org> wrote:
>> On Wed, Jul 11, 2018 at 6:11 PM Richard Yao <r...@gentoo.org> 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

Reply via email to