From owner-cvs-all@FreeBSD.ORG Tue Dec 13 08:31:56 2011 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68D7B1065673; Tue, 13 Dec 2011 08:31:56 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 0E1F38FC1E; Tue, 13 Dec 2011 08:31:55 +0000 (UTC) Received: from outgoing.leidinger.net (p4FC43C5B.dip.t-dialin.net [79.196.60.91]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id D200B84400D; Tue, 13 Dec 2011 09:31:40 +0100 (CET) Received: from unknown (IO.Leidinger.net [192.168.1.12]) by outgoing.leidinger.net (Postfix) with ESMTP id 1A0B859C1; Tue, 13 Dec 2011 09:31:38 +0100 (CET) Date: Tue, 13 Dec 2011 09:31:38 +0100 From: Alexander Leidinger To: Doug Barton Message-ID: <20111213093138.00007c9a@unknown> In-Reply-To: <4EE6B85B.9050701@FreeBSD.org> References: <201112072132.pB7LW6Aa042461@repoman.freebsd.org> <20111210214025.0000445d@unknown> <4EE3C9C8.9050709@FreeBSD.org> <4EE3CF42.6000703@freebsd.org> <4EE6B85B.9050701@FreeBSD.org> X-Mailer: Claws Mail 3.7.10cvs7 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: D200B84400D.AF971 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1, required 6, autolearn=disabled, ALL_TRUSTED -1.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1324369901.78353@e2wyCurtqPeE6KIpWP/7PA X-EBL-Spam-Status: No Cc: doc-committers@FreeBSD.org, re@FreeBSD.org, cvs-doc@FreeBSD.org, emulation@FreeBSD.org, cvs-all@FreeBSD.org, Nathan Whitehorn , Manolis Kiagias 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: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: **OBSOLETE** CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 08:31:56 -0000 On Mon, 12 Dec 2011 18:28:43 -0800 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 =CE=BC=CE=BC, 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.ht= ml > >> ). I think the best and safer way would be for bsdinstall to create > >> the link if possible. > >=20 > > 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. >=20 > 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? The current state: - the kernel has a hardcoded /compat/linux - the ports framework (not the linux_base port) does a mkdir -p $PREFIX before the install - the PREFIX for the linux_base ports is /compat/linux (POLA) The only part where we could do something in the port, is for the PREFIX. Now... what are the implications to change this? - ports exp-run and commit and ports-tree-retagging and rebuilding of the ports for the release - users which see a different prefix than they are use to - a mess in the linux_base port to determine every possibility what the user did to /compat and to try to do the right thing The last item is the most critical IMO. Personally I had once 2 different linux bases in /compat (activated by changing a link). I do not expect much users like this, but the point is, that we do not know what an user has in /compat, so messing around with it is dangerous. One thing what we could do is to check in the linux_base port if /compat is a symlink or not. If it isn't we error out and tell the user to fix it. But then... is this still POLA? In cases where /compat is a directory already, nothing bad will happen during an update, so no need to error out (one of our credos is "features, not policies"). I expect that in most cases it is already a symlink (when sysinstall was used to install a system, which should be true for the majority of normal users). I'm open to your suggestions. Bye, Alexander. --=20 http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137