> On Jul 11, 2018, at 6:23 PM, Michał Górny <mgo...@gentoo.org> wrote:
> 
> W dniu śro, 11.07.2018 o godzinie 18∶11 -0400, użytkownik Richard Yao
> napisał:
>>>> On Jul 11, 2018, at 4:43 PM, Rich Freeman <ri...@gentoo.org> wrote:
>>>> 
>>>> On Wed, Jul 11, 2018 at 4:34 PM Richard Yao <r...@gentoo.org> wrote:
>>>> 
>>>> On my system, /usr/portage is a separate mountpoint. There is no need to 
>>>> have on,h top level directories be separate mountpoints.
>>> 
>>> It makes sense to follow FHS.  Sure, I can work around poor designs by
>>> sticking mount points all over the place, or manually setting my
>>> config to put stuff in sane locations.  It makes more sense to put all
>>> the volatile stuff in /var, than to mix it up all over the place and
>>> get users to set up separate mountpoints to make up for it.
>> 
>> 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.
>> 
>> 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.
>>> 
> 
> And we're back to the usual Gentoo argument of 'it was like this for
> N years'.  So FYI, something 'being there for ~15 years' doesn't make it
> right.  It only means that:
> 
> a. Gentoo devs were wrong 15 years ago.
> 
> b. Gentoo devs are still wrong today.
> 
> c. Gentoo devs can't manage to make such a simple change because they're
> too concerned about hurting somebody's feelings about a path.
This does not answer my question. Is it really a FHS violation? The contents of 
/usr changes when doing updates using the system package manager. When not 
doing updates, it really is readonly and the FHS says that /usr is for readonly 
things. I do not see how it is different from anything else in /usr.

I have been thinking that having it there was compliant for years and honestly, 
I don’t see how it is not complaint. Saying it is not compliant is not an 
explanation.
> 
> -- 
> Best regards,
> Michał Górny


Reply via email to