From owner-freebsd-sysinstall@FreeBSD.ORG Thu Jul 8 22:18:44 2010 Return-Path: Delivered-To: freebsd-sysinstall@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E88521065672 for ; Thu, 8 Jul 2010 22:18:44 +0000 (UTC) (envelope-from BearPerson@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 538078FC1D for ; Thu, 8 Jul 2010 22:18:43 +0000 (UTC) Received: (qmail invoked by alias); 08 Jul 2010 22:18:42 -0000 Received: from port-92-204-43-35.dynamic.qsc.de (EHLO [192.168.0.130]) [92.204.43.35] by mail.gmx.net (mp008) with SMTP; 09 Jul 2010 00:18:42 +0200 X-Authenticated: #20254835 X-Provags-ID: V01U2FsdGVkX1/6H6EyCU/63xzmhiZkuOWdNeJ0bcfXpDOvG0jdTf gVYR1Nm2HsbCoQ Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Karsten Behrmann In-Reply-To: Date: Fri, 9 Jul 2010 00:18:42 +0200 Content-Transfer-Encoding: 7bit Message-Id: <61D8EE6E-12D9-4858-AB79-7BCCC5FA892C@gmx.net> References: To: freebsd-sysinstall@freebsd.org X-Mailer: Apple Mail (2.1081) X-Y-GMX-Trusted: 0 Subject: Re: Removing upgrade X-BeenThere: freebsd-sysinstall@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Sysinstall Work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 22:18:45 -0000 > I'll be on your side if there is any push back :) There is. Surprisingly, people were actually still using this in some cases. Mostly as a "clobber install" if they somehow managed to trash their binaries, sometimes as a quick-and-dirty update-to-current. Concensus (as far as I see on IRC) seems to be this: We re-add the feature, but we name it "restore" rather than "update", and do not advertise that it is in any way supposed to work as a method to update a system. Instead, it is a fixit option (potentially stuffed somewhere inside an appropriate submenu) that overwrites part of your install with fresh files from package. We should probably prefix a warning dialog "may eat your cat/dog/aunt". We didn't yet agree on what to do with /etc, suggestions include: a) Keep the current code b) Leave /etc untouched entirely c) Write fresh files to /etc/$file.restore.$date and leave originals alone d) Attempt to run mergemaster e) Any combination of the above Personally, I think we want something between b) and c). I don't see us maintaining a proper "safe merge" thing anytime soon, so we shouldn't try. The current code is dangerous and should be scrapped. If we're feeling particularly luxurious, we could let the user decide which areas they want protected/clobbered/augmented, potentially by dropping them into an editor for a simple filter definition file. If people want to still use this to update between -current commits, I guess we can't stop them, but it should not be an intended functionality. The less code we need for this the better: sysinstall is not really in the business of replacing mergemaster, our energies at writing and understanding code are better spent elsewhere. So Far, Karsten "BearPerson" Behrmann