From owner-freebsd-stable Mon Mar 22 12:42:56 1999 Delivered-To: freebsd-stable@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 6CEDA14E84 for ; Mon, 22 Mar 1999 12:42:55 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id FAA08542; Tue, 23 Mar 1999 05:42:52 +0900 (JST) Message-ID: <36F6AAEC.2BBCA159@newsguy.com> Date: Tue, 23 Mar 1999 05:41:16 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Mike Meyer Cc: stable@FreeBSD.ORG Subject: Re: Musings about tracking FreeBSD... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Meyer 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. And the only reason I don't say that this particular instance of cdrecord not working for you anymore probably won't ever happen again is that saying this would automatically break cdrecord again. ;-> Was this, by any chance, a 2.2.x -> 3.x upgrade? This is a far greater upgrade than a normal point release. In this case, cdrecord could have been broken because we completely changed our SCSI architecture. That is not something we do very often, I garantee. :-) > Of course, that leaves things that weren't install from /usr/ports out > in the cold. > > 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. :-) 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. 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. The particular case of cdrecord is unfortunate, because there isn't a *standard* interface for it to use. If it used a *standard* interface, it wouldn't get broken. And if it did even then, it would be a bug in FreeBSD. 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 :). -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Someone's trying to hack into our server." "Wow... How flattering!" "I know. There must be some mistake." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message