From owner-freebsd-current@FreeBSD.ORG Sun Dec 21 19:07:34 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E448716A4CE for ; Sun, 21 Dec 2003 19:07:34 -0800 (PST) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A1BC43D60 for ; Sun, 21 Dec 2003 19:07:32 -0800 (PST) (envelope-from adam@migus.org) Received: from ludo.migus.org ([68.55.80.136]) by comcast.net (sccrmhc11) with ESMTP id <2003122203073201100ih9dve>; Mon, 22 Dec 2003 03:07:32 +0000 Received: by ludo.migus.org (Postfix, from userid 80) id CA8CFA1028; Sun, 21 Dec 2003 22:07:31 -0500 (EST) Received: from 192.168.4.2 (SquirrelMail authenticated user adam) by mail.migus.org with HTTP; Sun, 21 Dec 2003 22:07:31 -0500 (EST) Message-ID: <59759.192.168.4.2.1072062451.squirrel@mail.migus.org> In-Reply-To: References: <20031221084531.GB31516@cactus.homeunix.org><20031221105925.GA1713@utgard.lodz.mm.pl><1072018131.715.10.camel@localhost> <3FE5B804.6000707@ispro.net.tr><20031221154129.GE2228@saboteur.dek.spc.org><60563.192.168.4.2.1072043423.squirrel@mail.migus.org><3FE620B5.9050201@ispro.net.tr> Date: Sun, 21 Dec 2003 22:07:31 -0500 (EST) From: "Adam C. Migus" To: "Garance A Drosihn" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal cc: Evren Yurtesen cc: current@freebsd.org Subject: Re: mergemaster feature suggestion... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2003 03:07:35 -0000 Garance A Drosihn said: > The problem is that the general solution is much harder to do > than it first appears. It is one thing to come up with a > solution that works well for what "you" (ie, any one developer) > need, but it is much more challenging to come up with a solution > that everyone can always use, for every upgrade, and that they > can rely on. You can not have installworld just blindly > removing files. That tactic *will* cause trouble. > > The fact that this issue keeps coming up is a good indication > that we need to do something. Every once-in-while I try my > own hand at implementing some solution, but so far I have not > come up with anything that I am 100% happy with. > Adopting the etcmerge port while having the installation install a fresh, reference /etc everytime for the comparison would solve this and most other problems people are talking about. Adam