From owner-freebsd-bugs@FreeBSD.ORG Sun Jan 5 21:10:01 2014 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 440FEDDF for ; Sun, 5 Jan 2014 21:10:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 30DFD13D6 for ; Sun, 5 Jan 2014 21:10:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s05LA1ij029106 for ; Sun, 5 Jan 2014 21:10:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s05LA1oO029105; Sun, 5 Jan 2014 21:10:01 GMT (envelope-from gnats) Date: Sun, 5 Jan 2014 21:10:01 GMT Message-Id: <201401052110.s05LA1oO029105@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Nathan Dorfman Subject: Re: misc/185480: WORLDTMP first in PATH during installworld X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Nathan Dorfman List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jan 2014 21:10:01 -0000 The following reply was made to PR misc/185480; it has been noted by GNATS. From: Nathan Dorfman To: Brooks Davis Cc: freebsd-gnats-submit@freebsd.org Subject: Re: misc/185480: WORLDTMP first in PATH during installworld Date: Sun, 5 Jan 2014 16:03:24 -0500 Thanks for the explanation. That just leaves one question: why are we bothering to create and populate ${INSTALLTMP}? Under normal circumstances, where ${WORLDTMP} exists, it doesn't seem to be used. In fact, it's missing the 'strip' binary, but it doesn't make a difference until I come along and try to run without ${WORLDTMP}... As for the rest, if the process is unsupported, then I guess I will stop doing it :) ... but I'd just like to state for the record that it seems to work perfectly fine here, after these workarounds. I think it's also possible to have a "correct" solution, by using the freshly built world instead of ${WORLDTMP} when ${MACHINE_ARCH} says so. If there is any interest at all, I can get that working and submit a patch. On Sun, Jan 5, 2014 at 2:30 PM, Brooks Davis wrote: > I believe that WORLDTMP is first the path to allow new versions of tools > to be used in the install process. It's critical that we do this or we > could only use new tool features after multiple major releases. > > It is not supported to build on one system and install on another. It > could be, but it isn't now. Apparently it's never been a high enough > priority for anyone, probably because there are plenty of workaround. > > The simplest workaround is to just do an installworld to some arbitrary > DESTDIR, tar up the result, remove schg flags on the target with > "chflags -R noschg /", and extracting the tarball. With the -DNO_ROOT > feature I added to the install targets a while back this is easily > accomplished even without root access on the build system. Just do > installworld with -DNO_ROOT and then use ${DESTDIR}/METALOG as the input > to tar. > > -- Brooks