From owner-freebsd-stable Mon Mar 22 13:28:23 1999 Delivered-To: freebsd-stable@freebsd.org Received: from guru.phone.net (guru.phone.net [209.157.82.120]) by hub.freebsd.org (Postfix) with SMTP id 7CC4814CF1 for ; Mon, 22 Mar 1999 13:28:21 -0800 (PST) (envelope-from mwm@phone.net) Received: (qmail 14893 invoked by uid 100); 22 Mar 1999 21:28:01 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 22 Mar 1999 21:28:01 -0000 Date: Mon, 22 Mar 1999 13:28:01 -0800 (PST) From: Mike Meyer To: stable@FreeBSD.ORG Subject: Re: Musings about tracking FreeBSD... In-Reply-To: <36F6AAEC.2BBCA159@newsguy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 23 Mar 1999, Daniel C. Sobral wrote: > > system call. Rebuilding cdrecord solved the problem, but this > > illustrates that the recommended procedure is incomplete - you need to > > reinstall all ports/packages as well, right? Is there a tool that > > Hardly ever, actually. A few ones might need reinstalling in some > cases, but most ports should continue to work just fine. That's actually what I expect. > Was this, by any chance, a 2.2.x -> 3.x upgrade? This is a far Nope. 3.0-RELEASE->3.1-STABLE (at the time of the 3.1-RELEASE release). > > Does anyone actually update all such things? Or do they do the more > > realistic thing, and just rebuild things that aren't from /usr/ports - > > or are, for that matter - when they break? Which would also be a > > perfectly reasonable attitude for /usr/src & make/make install > > vs. buildworkd/installworld, and which at least one person recommended > > to me in private mail. > > Whatever it works for you. :-) Yeah - I'm still considering it. I had been working on the (incorrect, obviously) that "make/make install" on the tree or parts of it the equivalent for patches in other platforms. > The reason "world" is necessary is that the interdependencies of the > build process are too complex for a simple "all" target. It *could* > be made to work, at the price making working in the source tree a > PITA. Well, it could be done with a new branch between -STABLE & -RELEASE, that had to build against the -RELEASE headers & libraries. But in general, yeah - having a branch that would build properly against *any* old version of the branch is a PITA, and something you don't run into in commercial build environments. > But most working programs should *continue* to work, new world or > not. That's one reason for using shared libraries, even: so they can > get the newer version (with bug fixes) without needing > recompilation. That has, in general, been my experience. *Including* programs that are built from /usr/src via make & make install. Sure, it's not guaranteed to work. But it sounds like neither is anything else that was on the system before the world got built. > So, it comes down to one getting used enough to know your way > around. I think we are still way ahead than anyone else when it > comes down to building the whole system (or even parts of it :). Certainly ahead of the BSD releases I dealt with before. NetBSD seems close, though.