From owner-freebsd-emulation@FreeBSD.ORG Tue Dec 13 20:23:15 2011 Return-Path: Delivered-To: emulation@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 7A27E1065672; Tue, 13 Dec 2011 20:23:15 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id B5D9D1501D5; Tue, 13 Dec 2011 20:23:14 +0000 (UTC) Message-ID: <4EE7B432.70000@FreeBSD.org> Date: Tue, 13 Dec 2011 12:23:14 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: John Baldwin References: <201112072132.pB7LW6Aa042461@repoman.freebsd.org> <4EE3CF42.6000703@freebsd.org> <4EE6B85B.9050701@FreeBSD.org> <201112130842.38610.jhb@freebsd.org> In-Reply-To: <201112130842.38610.jhb@freebsd.org> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: doc-committers@freebsd.org, re@freebsd.org, cvs-doc@freebsd.org, emulation@freebsd.org, cvs-all@freebsd.org, Nathan Whitehorn , Alexander Leidinger Subject: Re: cvs commit: doc/en_US.ISO8859-1/books/handbook/desktop chapter.sgml doc/en_US.ISO8859-1/books/handbook/linuxemu chapter.sgml X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 20:23:15 -0000 On 12/13/2011 05:42, John Baldwin wrote: > On Monday, December 12, 2011 9:28:43 pm Doug Barton wrote: >> On 12/10/2011 13:29, Nathan Whitehorn wrote: >>> On 12/10/11 15:06, Manolis Kiagias wrote: >>>> On 10/12/2011 10:40 μμ, Alexander Leidinger wrote: >>>>> On Wed, 7 Dec 2011 21:32:06 +0000 (UTC) Manolis Kiagias >>>>> wrote: >>>>> >>>>> CCing re@, emulation@ and nwhitehorn@ due to a possible impact in the >>>>> upcomming release. >>>>> >>>>>> Modified files: >>>>>> en_US.ISO8859-1/books/handbook/desktop chapter.sgml >>>>>> en_US.ISO8859-1/books/handbook/linuxemu chapter.sgml >>>>>> Log: >>>>>> Use /compat/linux/proc instead of /usr/compat/linux/proc as the >>>>>> mount point of linproc in the examples, since: >>>>>> >>>>>> - linux_base always installs to /compat and creates it as a >>>>>> directory if it does not exist as a symlink >>>>>> - Custom installations (not done by sysinstall(8)) may not >>>>>> have /compat at all >>>>>> - The linuxemu chapter uses /compat anyway (except a single >>>>>> example, fixed) >>>>>> - The new bsdinstall(8) does not create /compat either as directory >>>>>> or symlink >>>>> Looks like a bug in bsdinstall (and linux_base) to me. What you write >>>>> here means that a new release with bsdinstall instead of sysinstall may >>>>> cause problems where /compat is in a small partition and /usr in a big >>>>> partition (even if it creates a big one by default, an user may change >>>>> this). I suggest to fix bsdinstall before the release of 9.0. It also >>>>> changes what is expected by long-term users. >>>> >>>> Yes, this was discussed in the PR (see >>>> http://lists.freebsd.org/pipermail/freebsd-doc/2011-December/019270.html >>>> ). I think the best and safer way would be for bsdinstall to create >>>> the link if possible. >>> >>> This is very easy to do, and the correct place is in >>> /usr/src/usr.sbin/bsdinstall/scripts/config. I don't have a good sense >>> of what the correct logic is, however, and so would appreciate either >>> guidance or patches from emulation-types. >> >> I don't understand why the linux_base ports are not sorting this out on >> their own. Why should this be a function of the installer? > > It's a sysadmin's decision what /compat is. It could be a directory on / > (which is fine if you have one-big filesystem for everything). It could be > a mountpoint for another filesystem. It could be a symlink to a directory > on some other filesystem. All these are valid, and the various ABI packages > should not be trying to set that policy. Right to all that ... I wasn't suggesting that the ports set a policy, just that they should sort out whether a /compat exists or not, and if not, create a sensible one. > I do think the installer can set a > good initial policy for this just as it can for /home. This is where I disagree. Everyone needs a /home, not all of our users need /compat. The installer should be focused on things that everyone needs. The ports that need fairings should be responsible for creating them. Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/