From owner-freebsd-questions@FreeBSD.ORG Wed Jun 26 02:22:42 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 61875E53 for ; Wed, 26 Jun 2013 02:22:42 +0000 (UTC) (envelope-from mike@skew.org) Received: from chilled.skew.org (chilled.skew.org [70.90.116.205]) by mx1.freebsd.org (Postfix) with ESMTP id 2DB90121C for ; Wed, 26 Jun 2013 02:22:41 +0000 (UTC) Received: from chilled.skew.org (localhost [127.0.0.1]) by chilled.skew.org (8.14.5/8.14.4) with ESMTP id r5Q2MetT087351 for ; Tue, 25 Jun 2013 20:22:40 -0600 (MDT) (envelope-from mike@chilled.skew.org) Received: (from mike@localhost) by chilled.skew.org (8.14.5/8.14.4/Submit) id r5Q2MdJO087350 for freebsd-questions@freebsd.org; Tue, 25 Jun 2013 20:22:39 -0600 (MDT) (envelope-from mike) From: Mike Brown Message-Id: <201306260222.r5Q2MdJO087350@chilled.skew.org> Subject: Re: Should I be able to use mergemaster with freebsd-update? In-Reply-To: <2528F3423B004DCAAFC9B9F927C42D9E@geniepc2011> To: freebsd-questions@freebsd.org Date: Tue, 25 Jun 2013 20:22:39 -0600 (MDT) X-Whoa: whoa. X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 02:22:42 -0000 On Tue, Jun 25, 2013, at 15:29, Eugene wrote: > I do not quite understand. Is the freebsd-update upgrade process > completely broken? IMHO it is partially broken; I'm not doing anything special. How broken it is depends on what's getting changed. Most of what the system is designed to do, it indeed does very well. It also overlaps some of the functionality of mergemaster in that it automatically merges as many files as it can, which is nice. Where it is under-designed and under-implemented is in its rudimentary handling of un-mergeable files, and in its total lack of support for the regeneration of /etc/*.db files (like the, uh, rather important password database) and sendmail aliases - things that you would handle via mergemaster in an ordinary, source-based upgrade, but which you must now figure out how to do by hand, without any guidance, and they really don't make it easy for you. When I upgraded from 8.1 to 8.3, I avoided the issue altogether by not really merging anything; when dumped into the empty text editor, I just loaded my old files and made no changes. In the Handbook, there's an assumption that people who do this will go back later and figure out what merges are needed, but the resources you need to do that don't exist; if you don't do the merge when prompted, you don't get a second chance. In fact, even if you do it when prompted, you need to get it right, or start the whole process over. My upgrade to 8.3 worked out OK because I got lucky; freebsd-update hadn't fetched new, stock password database files. The unmergeable files were all text files, nothing requiring anything to be regenerated. But this time around, for 8.3 to 8.4, I am trying to do everything I'm supposed to, actually merging when prompted. The fact that it's a *really* manual process is a pain, but as I mentioned, I found a way to at least run sdiff from another window, which made it a lot easier, although still more tedious than it should be. The main problem this time is that I'm not so lucky with the password files, because for 8.4, freebsd-update has fetched new, stock .db files to put in /etc. So, yes, I was able to merge master.passwd & passwd, but that's not very helpful since the .db files won't be in sync with them. If allow my custom password database to be overwritten with these new, stock .db files, obviously that's bad. And because freebsd-update makes no special allowance for the .db files, it actually put a zero-byte file in the staging area instead of the real .db file (as if it were going to have me modify it with an editor). So if I proceed, my password database will actually be overwritten with an empty file, which I believe would be a disaster. The solution, I feel, is to: 1. make freebsd-update recognize files that most likely need to be regenerated instead of replaced - /etc/*.db, at least, if not also any other binary file, and some of the things that would be generated by 'make' in /etc/mail. The user should be informed that these files need to be regenerated, if there's no way to just regenerate them automatically when their companion source files have been updated or merged. 2. make freebsd-update run mergemaster on the unmergeable text files, instead of dumping the user into an empty text editor for each one. For each file that can't be automatically merged, mergemaster will give the user the opportunity to choose whether to keep the old file, replace it with the new file, interactively merge them via sdiff, or do nothing. It is also smart enough to realize that when certain files are being touched, such as /etc/master.passwd, /etc/mail/aliases, etc. you'll need to run pwd_mkdb, cap_mkdb, services_mkdb, or newaliases...and it will run those for you (or remind you to do it). For this to work, mergemaster would need some tweaking to deal with freebsd-update's staging area, and to not duplicate any of the work that freebsd-update does. I keep hoping that maybe there's some nuance of the process that I'm missing, and that all of this really is not a problem.. user error, or not reading the docs carefully enough, you know? But Mark Felder's comments seem to confirm that it's a real issue.