From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31581 invoked from network); 24 Oct 2004 11:29:21 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 24 Oct 2004 11:29:21 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1CLgYr-0003Fz-0D for arch-gentoo-portage-dev@lists.gentoo.org; Sun, 24 Oct 2004 11:29:21 +0000 Received: (qmail 11294 invoked by uid 89); 24 Oct 2004 11:29:19 +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 2675 invoked from network); 24 Oct 2004 11:29:19 +0000 Message-ID: <417B91B8.5060704@libero.it> Date: Sun, 24 Oct 2004 13:27:52 +0200 From: andrea ferraris User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: gentoo-portage-dev@lists.gentoo.org References: <4176E087.7090909@libero.it> <200410211030.29408.pauldv@gentoo.org> <200410241115.21029.pauldv@gentoo.org> In-Reply-To: <200410241115.21029.pauldv@gentoo.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at libero.it serv1 Subject: Re: [gentoo-portage-dev] Conary X-Archives-Salt: f6f85a05-df2a-4ca8-8ad7-1016a8e94b75 X-Archives-Hash: 43dcc0fa130d0c0ec149f31147a7b021 Paul de Vrieze wrote: > On Sunday 24 October 2004 05:18, Ed Grimm wrote: > >>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.) > > > This is what dispatch-conf will do if you give it time to work. For > dispatch-conf to work you need to initialise it first. It works with > three-way diffs, so without a reference (which gets created the first time a > config file is updated with dispatch-conf) it doesn't work. For the rest, I > suggest you write up a patch to dispatch-conf to allow it to ignore certain > files. However it normally works quite well with fstab as the default one > hardly changes, and you'd want to know about those changes anyway. Thx to you and other kind replying people > I don't made yet my homeworks (studying dispatch-conf), so I was replying to Ed (with congrats), saying that was needed a 3 time diff. I think that could be more convenient the dispatch-conf way, but conceptually the creation of a reference is not mandatory. It's enough a diff between the actually installed and modified file and the original one of that version, since the system know which is the version of the original one. Then it knows which are the original lines that disappeared or changed and at that point it could delete such lines (or those that substitute them) from the new standard cfg file and merge only the remaining diffs and in any case it shouldn't never substitute custom changes with standard in cfg files. Then it could not be bad one comment line at the beginning of new std cfg file where is written what changed and why (I know that for the developers could be annoying, but it should not take more than 1-2 minutes). >>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. > > > Well, go ahead > There are no problem, I know neither python neither perl, so I'm the perfect candidate to translate your perl script in python ;-) because I'd like to learn python. Anyway I know awk. Andrea P.S.: I'd like that someone for curiosity studied Conary to see what and how can be ported to gentoo portage, but I seen that my attempt has not been a very big success ;-), so maybe in my spare time, I'll try to do such thing myself and report here the results in the hope that you can teach me some about portage. -- gentoo-portage-dev@gentoo.org mailing list