From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30308 invoked from network); 24 Oct 2004 03:21:35 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 24 Oct 2004 03:21:35 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1CLYwp-0000MX-Fl for arch-gentoo-portage-dev@lists.gentoo.org; Sun, 24 Oct 2004 03:21:35 +0000 Received: (qmail 29323 invoked by uid 89); 24 Oct 2004 03:21:27 +0000 Mailing-List: contact gentoo-portage-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail Reply-To: gentoo-portage-dev@lists.gentoo.org X-BeenThere: gentoo-portage-dev@gentoo.org Received: (qmail 22610 invoked from network); 24 Oct 2004 03:21:26 +0000 Date: Sat, 23 Oct 2004 22:18:56 -0500 (EST) From: Ed Grimm X-X-Sender: ed@lorp.ed.vnet To: gentoo-portage-dev@lists.gentoo.org In-Reply-To: <200410211030.29408.pauldv@gentoo.org> Message-ID: References: <4176E087.7090909@libero.it> <200410211030.29408.pauldv@gentoo.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [gentoo-portage-dev] Conary X-Archives-Salt: 41181b49-a3be-42c1-aab3-64ae33c2cfb9 X-Archives-Hash: edbc7bb3097d1aa4c8c738d6c5e9ffd5 On Thu, 21 Oct 2004, Paul de Vrieze wrote: > On Thursday 21 October 2004 00:02, andrea ferraris wrote: >> The first one is simple: in a litle gentoo system that I'm >> managing for a year now with authomatic nightly updates, >> I had to update almost manually about a hundred of >> configuration files. The system (gentoo) is well designed, >> so, if I didn't update, all works because the original >> configuration files stay in place, but for the better and >> also only for the good, the thing to do is to use etc-update >> to update such configuration files. The problem is that such >> process is really time consuming and error prone, so it's >> not very good. > > You might want to try dispatch-conf. It is superior to etc-update in > many aspects, and it comes with gentoolkit. Further there is normally > no need to update every night. While there is no problem with it, it > will increase the maintenance load unnecessarilly. Reading the dispatch-conf(1") manpage (1"?), I see that it does a certain amount of reduction of makework. However, it does nothing to fix my primary annoyance with Gentoo's attempts to update my /etc files. My issue is: Gentoo's patch system does not take current state into account in any appropriate manner. This means that any file in /etc which I have made changes will be updated improperly; I'll therefore need to either throw out new changes or adapt them to my changes every time Gentoo considers updating them. As an example, I'm not using the standard Gentoo partition layout. This means that, every so often, Gentoo tries to "fix" my fstab. It generally does this by inserting the new values it wants to have for each partition into the file, producing an fstab file which has multiple mount points with the same names, but different devices and file system formats. I seem to recall one of the earlier attempts entirely eliminated my config. I'd have changed distributions over this if these files were installed immediately. Other files which tend to be incredibly frustrating are basic config files. For example, /etc/etc-update.conf. Every time an upgrade decides it wants to check on the status of this file, it decides that, on the whole, I was mistaken regarding my choice of difference viewer, and the various other options I specified. I've generally stayed fairly silent on this matter, because it appeared that people were aware of the problem, and I have a difficult time not frothing over it. However, it's apparent that the understanding that the developers have does not come anywhere close to understanding my problem with the current system. Excluding program directories (for example, /etc/init.d), all changes to existing /etc files should compensate for changes that the local administrator has made. For example, when upgrading a configuration file, the new version should, as much as possible, retain the changes that the local administrator has made. When the ext3 filesystem tools add a new option, any attempts to update /etc/fstab should ignore any partitions that aren't ext3. It should not add any partitions that it feels are missing, either due to having ignored a reiserfs partition or due to that partition not being there. It should not alter any swap partitions that haven't been modified according to a change the ext3 maintainer previously saw - it's possible it may have not been installed here, it's possible the administrator backed it out. It should NEVER try to change the partition type (for example, from ext3 to xfs, like it currently wants to do.) If people are interested, I could potentially write a tutorial on methods one could utilize to perform such functions. Note that this would be written to writing the code in perl, as I don't know python well, and it doesn't feel natural to me. Ed -- gentoo-portage-dev@gentoo.org mailing list