From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id D6D2C138334 for ; Wed, 11 Jul 2018 22:26:44 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B849EE0884; Wed, 11 Jul 2018 22:26:39 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 369ABE0806 for ; Wed, 11 Jul 2018 22:26:39 +0000 (UTC) Received: from [192.168.5.121] (pool-96-232-204-110.nycmny.fios.verizon.net [96.232.204.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id A2F10335C07 for ; Wed, 11 Jul 2018 22:26:37 +0000 (UTC) From: Richard Yao Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 (1.0) Date: Wed, 11 Jul 2018 18:26:35 -0400 Subject: Re: [gentoo-dev] rfc: moving default location of portage tree Message-Id: <9CF18E79-4B22-4FB3-8390-F41E0062F2F6@gentoo.org> References: <20180709172136.GA17068@linux1.home> <1531161811.1159.13.camel@gentoo.org> <20180709201113.GB17593@linux1.home> <1531167218.1159.15.camel@gentoo.org> <20180709211410.GA17986@linux1.home> <2f7c8b18-8c5d-2931-14a7-9d6d1e00526d@gentoo.org> <29b55e16-bb2e-5a98-13e2-e1482441b417@gentoo.org> <8b47a97d-37be-652a-0298-7e7082506b53@iee.org> <50aa6222-d97c-6fd0-0884-23b27f494135@gentoo.org> <20180710200923.GA21918@linux1.home> <88409c1e-eb34-dad8-c524-2b44de5bc91b@iee.org> <5f2b3a86-c7d5-f588-5ea3-4c13055d8324@gentoo.org> <1531347809.20022.3.cam el@gentoo.org> In-Reply-To: <1531347809.20022.3.camel@gentoo.org> To: gentoo-dev@lists.gentoo.org X-Mailer: iPad Mail (15F79) X-Archives-Salt: d0ef2bbb-4b9a-4927-b79a-6bdacf11d344 X-Archives-Hash: c51d9d7951ff0425cd05e0aab16f0c13 > On Jul 11, 2018, at 6:23 PM, Micha=C5=82 G=C3=B3rny wr= ote: >=20 > W dniu =C5=9Bro, 11.07.2018 o godzinie 18=E2=88=B611=E2=80=89-0400, u=C5=BC= ytkownik Richard Yao > napisa=C5=82: >>>> On Jul 11, 2018, at 4:43 PM, Rich Freeman wrote: >>>>=20 >>>> On Wed, Jul 11, 2018 at 4:34 PM Richard Yao wrote: >>>>=20 >>>> On my system, /usr/portage is a separate mountpoint. There is no need t= o have on,h top level directories be separate mountpoints. >>>=20 >>> 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. >>=20 >> Is it a violation of the FHS? /usr is for readonly data and the portage t= ree is generally readonly, except when being updated. The same is true of ev= erything else in /usr. >>=20 >> I am confused as to how we only now realized it was a FHS violation when i= t has been there for ~15 years. I was under the impression that /usr was the= correct place for it. >>>=20 >=20 > 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: >=20 > a. Gentoo devs were wrong 15 years ago. >=20 > b. Gentoo devs are still wrong today. >=20 > 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 n= ot doing updates, it really is readonly and the FHS says that /usr is for re= adonly 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 honest= ly, I don=E2=80=99t see how it is not complaint. Saying it is not compliant i= s not an explanation. >=20 > --=20 > Best regards, > Micha=C5=82 G=C3=B3rny