Date: Mon, 04 Mar 1996 22:46:25 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Ben Kirkpatrick <ben@guppy.pond.net> Cc: freebsd-stable@freebsd.org Subject: Re: Stable vs. local changes at ISP Message-ID: <27000.826008385@time.cdrom.com> In-Reply-To: Your message of "Mon, 04 Mar 1996 20:11:24 PST." <Pine.BSF.3.91.960304200435.14024A-100000@guppy.pond.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 1) By using sup to update the src tree here, will I indanger some of > the local changes we've made? (i.e. des and 16char usernames) You probably wouldn't want to do it like that (e.g. yes, it would endanger your changes). Instead, sup the CVS tree and check out a copy of -stable somewhere. Work in this directory and use CVS update to periodically sync your tree with ours. CTM will preserve your changes and also notify you when you've modified something which is now in conflict with us. It won't do this in a very pleasant way, mind you (unless you happen to like lots of regions marked with `<<<<<<' characters in your source files :-), but it's better than the alternative. > 2) make world sometimes causes problems on a running system, possibly > updating libs before the appropriate binaries and rebuilding kernel. (i.e. > w, and who always act funny) Yeah, we know. This is often unavoidable, sorry! > 3) Any comment on this idea: We do system maint on sunday nights. > Would it be acceptable/safe to run sup and make the day before, and have > it actually install while in single-user mode? How do you postpone the > install step? With a `make world?' You don't, I'm afraid. There are two options, that I see: 1. Make a custom version of the world target that doesn't install anything, then go find and fix all the other Makefiles which make assumptions about various things being in /usr/bin, /usr/include and /usr/lib. This is a big job, which is why it's been postponed for so long. It's an especially nasty problem for the compiler tools if you're trying to go for 100% clean "no external dependencies" strategy. 2. Install with DESTDIR pointing somewhere else, then devise a scheme whereby you reboot and "swap" to the new populated tree as your root. Keep the old one around for reversion in case it doesn't work. Making this scheme work actually has other merits - you could hypothetically run both 2.1 and 2.2 on the same machine, for example. You'd have to do a chroot() of some sort in /sys/kern/init_main.c before running what's typically /sbin/init, but it's not undoable. In fact, I think I'll give it a shot right now, just to see what happens.. :-) Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?27000.826008385>