Date: Wed, 19 Jul 2000 12:51:00 -0700 From: Marcel Moolenaar <marcel@cup.hp.com> To: Bruce Evans <bde@zeta.org.au> 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: <397606A4.9D2717AB@cup.hp.com> References: <Pine.BSF.4.21.0007200402240.7415-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote:
>
> 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.
Good point. That should make it work across hosts as well and thus
enables us to copy the binaries to the object tree. I still don't think
we should do that, because that would prevent us from mounting /usr/obj
read-only during an installworld.
> The temporary directory could also be in a fixed
> place under ${DESTDIR}. Concurrent installworlds can only be expected to
> work for separate ${DESTDIR}s.
Yes. Technically speaking, we only have to save binaries when we're
installing in directories that are in PATH. I don't think all the logic
to optimize that weights up the increase in complexity we'll add to the
makefiles...
> Copying sh is almost a no-op since the full path to /bin/sh is often used.
> Similarly for perl.
We probably need to fix that or make sure that we handle it properly. We
could for example delay installation of sh and perl (and others) until
everything else is done. I'll dig into this...
> I think it would be better to copy the binaries early and restrict the
> path for all ather steps of the build.
I think that would unnecessary restrict what we can use during a build.
Restricting what we can use during an install is less intrusive, because
you should basicly only need to do an install...
> > > 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.
Precisely.
--
Marcel Moolenaar
mail: marcel@cup.hp.com / marcel@FreeBSD.org
tel: (408) 447-4222
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?397606A4.9D2717AB>