From owner-freebsd-questions@FreeBSD.ORG Thu Jun 24 19:19:26 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FC1E16A4CE for ; Thu, 24 Jun 2004 19:19:26 +0000 (GMT) Received: from outbox.allstream.net (outbox.allstream.net [207.245.244.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id F191343D55 for ; Thu, 24 Jun 2004 19:19:25 +0000 (GMT) (envelope-from epilogue@allstream.net) Received: from localhost (mon-pq62-165.dial.allstream.net [216.123.143.101]) by outbox.allstream.net (Allstream MTA) with SMTP id AB21C61A8 for ; Thu, 24 Jun 2004 15:18:36 -0400 (EDT) Date: Thu, 24 Jun 2004 15:18:15 -0400 From: epilogue@allstream.net Message-Id: <20040624151815.6608c193@localhost> In-Reply-To: References: <20040624041443.5d86b160@localhost> X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i386-portbld-freebsd4.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-questions@FreeBSD.org Subject: Re: alternative method for make / install world --- ? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2004 19:19:26 -0000 On Thu, 24 Jun 2004 13:17:29 -0400 Garance A Drosehn wrote: > At 4:14 AM -0400 6/24/04, epilogue@allstream.net wrote: > >hello all, > > > >I have recently been mulling over an article which proposes > >an abridged set of steps for updating the system. > > > >----------- > >http://www.bsdnews.org/03/bsd_update.php > > > >alias rebuild 'cd /usr/src && make update && make world && > > make kernel && mergemaster' > >----------- > > > >in a nutshell, the author proposes the following steps: > > > >1) rebuild > >2) answer the mergemaster prompts > >3) reboot > >4) all done hello all, first of all, thank you for the thoughtful feedback. i'm actually not trying to be lazy or cut corners here, i was just trying to understand the risks involved with the process advocated by this author. all in all, you've pretty much confirmed what i had suspected. > > We have a list of steps which we believe to be reliable. We have > absolutely no reason to add in steps "just to annoy you". We are > just as eager to have a quick system rebuild as anyone else would > be. You can often get away with skipping some of those steps, but > if you DO skip them, then YOU are responsible when something does > go wrong. And sooner or later, it will go wrong. You can bet on > it. You should expect it. By that I mean, *when* something does > go wrong, then you should immediately suspect that the problem is > due to your procedure. You should not "forget" that you have > refused to follow the recommended procedure, and you should not > come yelling at anyone else because "they broke your system". > > In the case of this author, he is tracking the 4.x-stable branch. the website provides tips on running fbsd and, given the reaction here, this particular article is likely not the best advice over the long-term. i am planning to drop the author a line linking to this thread. perhaps he'd consider revising the text or adding a brief warning, so that no hapless newbs end up getting burnt. once again, thank you all. > At this point in time, that branch sees very very little activity, > and because of that his strategy has probably worked quite well > for him. However, it will not work as well on the -current branch. > And very soon we will be moving to 5.3-stable as "the stable > branch", and after we do then his strategy is much more likely to > run into serious problems. And when it does, it will be you with > the broken system, and it may be that you will be the only one > who will be able to fix whatever was broken. > > Think if it this way. We have a list of steps that we document. > If you want to use some alternate list, then what makes you think > we will test *our* changes with *your* alternate strategy? We > will not. Sooner or later, something will break. On the one > hand we will feel bad for you, but on the other hand we can not > help you if you refuse to follow the steps that we have found to > be the most reliable. > > Yes, it is tempting to take shortcuts. But sooner or later you > will be burned by taking them. > > -- > Garance Alistair Drosehn = gad@gilead.netel.rpi.edu > Senior Systems Programmer or gad@FreeBSD.org > Rensselaer Polytechnic Institute; Troy, NY; USA >