Date: Sun, 5 Jan 2014 21:30:01 GMT From: Brooks Davis <brooks@freebsd.org> To: freebsd-bugs@FreeBSD.org Subject: Re: misc/185480: WORLDTMP first in PATH during installworld Message-ID: <201401052130.s05LU1e3034360@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR misc/185480; it has been noted by GNATS.
From: Brooks Davis <brooks@freebsd.org>
To: Nathan Dorfman <na@rtfm.net>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201401052130.s05LU1e3034360>