From owner-freebsd-bugs@FreeBSD.ORG Sun Jan 5 21:30: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 777D5544 for ; Sun, 5 Jan 2014 21:30: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 6486915A7 for ; Sun, 5 Jan 2014 21:30: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 s05LU1QM034361 for ; Sun, 5 Jan 2014 21:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s05LU1e3034360; Sun, 5 Jan 2014 21:30:01 GMT (envelope-from gnats) Date: Sun, 5 Jan 2014 21:30:01 GMT Message-Id: <201401052130.s05LU1e3034360@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Brooks Davis 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: Brooks Davis List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jan 2014 21:30:01 -0000 The following reply was made to PR misc/185480; it has been noted by GNATS. From: Brooks Davis To: Nathan Dorfman Cc: freebsd-gnats-submit@freebsd.org Subject: Re: misc/185480: WORLDTMP first in PATH during installworld Date: Sun, 5 Jan 2014 15:27:01 -0600 On Sun, Jan 05, 2014 at 04:03:24PM -0500, Nathan Dorfman wrote: > 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}... Hmm, right, I'd forgotten about INSTALLTMP. With that in mind I think you may be correct. We shouldn't need WORLDTMP at all. > 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. If it can be done without adding much more complexity it's probably worth doing. I'm a bit skeptical that it will be easy to get the built world to actually work in the general case where things in INSTALLTMP depend on a new libc but it should be possible. -- Brooks