The following reply was made to PR misc/185480; it has been noted by GNATS.
From: Nathan Dorfman <[email protected]> To: Brooks Davis <[email protected]> Cc: [email protected] 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 <[email protected]> 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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[email protected]"
