Date: Thu, 20 Jul 2000 04:09:43 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Marcel Moolenaar <marcel@cup.hp.com> Cc: Sheldon Hearn <sheldonh@uunet.co.za>, Marcel Moolenaar <marcel@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src Makefile.inc1 Message-ID: <Pine.BSF.4.21.0007200402240.7415-100000@besplex.bde.org> In-Reply-To: <39755F9B.30593B39@cup.hp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 19 Jul 2000, Marcel Moolenaar wrote:
> Sheldon Hearn wrote:
> > First, could you put the files somewhere in the obj tree so that they
> > aren't lost in the case of a reboot on a machine which mounts /tmp in
> > volatile storage?
>
> I prefer to use /var/tmp in that case. There's a problem with multiple
> concurrent installworlds if you save the binaries in the shared object
> tree.
Using separate temporary directories should handle that in the same way
as it does when /tmp is used. You should use mktmp(1) instead of $$ in
/tmp. $$ is probably secure enough in the obj tree since the obj tree
should be owned by root. The temporary directory could also be in a fixed
place under ${DESTDIR}. Concurrent installworlds can only be expected to
work for separate ${DESTDIR}s.
Copying sh is almost a no-op since the full path to /bin/sh is often used.
Similarly for perl.
I think it would be better to copy the binaries early and restrict the
path for all ather steps of the build.
> > Second, can mtree be added to that list so that revs 1.154 and 1.155 be
> > reverted?
>
> If we don't need mtree in the bootstrap-tools, than we sure need to save
> it during installworld. This can only be done if the mtree changes are
> reverted, right?
But we do need it in bootstrap-tools.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0007200402240.7415-100000>