From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1RFrL7-0007ij-FO for garchives@archives.gentoo.org; Mon, 17 Oct 2011 17:51:06 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3627421C0CE; Mon, 17 Oct 2011 17:50:55 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 4315D21C0CD for ; Mon, 17 Oct 2011 17:50:24 +0000 (UTC) Received: from [10.111.234.67] (unknown [184.151.127.163]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: axs) by smtp.gentoo.org (Postfix) with ESMTPSA id 1F1691B4003 for ; Mon, 17 Oct 2011 17:50:22 +0000 (UTC) References: <20111012044023.GA8203@waltdnes.org> <1318518871.3885.3.camel@TesterBox.tester.ca> <20111013180547.4973defa@googlemail.com> <4416149.yvcg9DIAd9@pc> <4E994AEF.5030002@mailstation.de> <4E9A0414.7030603@gentoo.org> <4E9AD392.30503@gentoo.org> <4E9B261B.1010304@gentoo.org> <4E9C51A9.1080006@gentoo.org> <4E9C64BD.7070008@gentoo.org> In-Reply-To: <4E9C64BD.7070008@gentoo.org> 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 (iPhone Mail 8C148a) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-2--883279182 Message-Id: Cc: "gentoo-dev@lists.gentoo.org" X-Mailer: iPhone Mail (8C148a) From: Ian Stakenvicius Subject: Re: [gentoo-dev] supporting /usr on separate partition Date: Mon, 17 Oct 2011 13:50:04 -0400 To: "gentoo-dev@lists.gentoo.org" X-Archives-Salt: X-Archives-Hash: 7dd0a95f9581a70d9c8bbc0eb13e5292 --Apple-Mail-2--883279182 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii ...and recombining again.. On 2011-10-17, at 1:24 PM, Zac Medico wrote: > On 10/17/2011 09:02 AM, Ian Stakenvicius wrote: >> Splitting this up since i'm kind of starting two threads here.. >>=20 >> ----- Documentation discussion ----- >> On 16/10/11 02:44 PM, Zac Medico wrote: >>>=20 >>> Well, you'll have to define the meaning of "support" in this context. I >>> simply said that it shouldn't be encouraged, with me reason being that >>> it tends to add unnecessary complexity (in violation of the KISS >>> principle [1]). >>>=20 >>=20 >> I would agree with this (that it shouldn't be encouraged), but I don't >> think the Handbook is encouraging it now, as it is written.. >=20 > It depends on how you define "encouraging" in this context. The fact > that /usr is shown as a separate partition might be considered > "suggestive" if not "encouraging". If a user takes that suggestion > without knowing the consequences (special initramfs or linuxrc init > wrapper configuration), then then it could cause some disappointment > when they finally discover the consequences. >=20 >> ----- Support/implementation discussion ----- >>=20 >>> ... If people want that, I think it's perfectly >>> reasonable to expect them to use either an initramfs or a simple linuxrc= >>> approach [2] to ensure that /usr is mounted before init starts.=20 >>=20 >> ...this would make sense, although in terms of "support" i think it >> would be appropriate that we would provide this linuxrc wrapper on any >> init system that needs /usr mounted. >=20 > If someone wants to take on the burden of maintaining an init wrapper > like that, then I guess that's fine. However, I wouldn't consider it to > be an absolute requirement. I think it would be fine (maybe preferable) > to simply provide a doc that describes how to mount /usr via an > initramfs or linuxrc init wrapper. Such a doc would only be needed by > those users who require that /usr be on a separate partition. This makes sense. So the Handbook could be updated with a caveat after the l= arge partition example to say something like "/usr on it's own partition nee= ds special consideration, please see XXXXX" ... this works.= --Apple-Mail-2--883279182 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
...and recombining again..
On 2011-10-17, at 1:24 PM, Zac Medico <zmedico@gentoo.org> wrote:

On 10/17/2011 09:02 AM, Ian Stakenvicius wrote:
Splitting this up since i'm kind of st= arting two threads here..
<= span>
----- Documenta= tion discussion -----
On 16/10/11 02:44 PM, Zac Medico wrote:

Well, you'll= have to define the meaning of "support" in this context. I
simply said that it shouldn't be encouraged, with me reason being that
it tends to add unnecessary complexity (in violation of the KIS= S
principle [1]).


I would agree with this (that it shouldn't be enco= uraged), but I don't
= think the Handbook is encouraging it now, as it is written..

It depends on how you define "encouraging" in= this context. The fact
that /usr is shown as a separate par= tition might be considered
"suggestive" if not "encouraging"= . If a user takes that suggestion
without knowing the conseq= uences (special initramfs or linuxrc init
wrapper configurat= ion), then then it could cause some disappointment
when they= finally discover the consequences.

----- Support/implementation discussion -----
<= /blockquote>

... If people want that, I= think it's perfectly
reasonable to expect them to use eith= er an initramfs or a simple linuxrc
approach [2] to ensure= that /usr is mounted before init starts.

...this would make sense, although in terms of "support" i thin= k it
would be appropr= iate that we would provide this linuxrc wrapper on any
init system that needs /usr mounted.

If someone wants to take on the bur= den of maintaining an init wrapper
like that, then I guess t= hat's fine. However, I wouldn't consider it to
be an absolut= e requirement. I think it would be fine (maybe preferable)
t= o simply provide a doc that describes how to mount /usr via an
initramfs or linuxrc init wrapper. Such a doc would only be needed by
those users who require that /usr be on a separate partition.

This makes sense.  So the Handbook could be updated with a caveat afte= r the large partition example to say something like "/usr on it's own partit= ion needs special consideration, please see XXXXX" ... this works.= --Apple-Mail-2--883279182--