Re: [gentoo-portage-dev] Conary - dispatch-conf

Hi there, i've been putting in alot of work on dispatch-conf lately,
adding features i personally need, and features that it should have. I
have a new version of dispatch-conf posted at bug:
http://bugs.gentoo.org/show_bug.cgi?id=68618

i believe it will solve one of your major problems with dispatch-conf as
i have added a new option called "config file freezing" which allows you
to specify config files you never want to be overwritten, like
/etc/fstab /etc/password and /etc/group and so on. instead it will take
the new files that portage tries to pass out and apply them to rcs (or
archive them through whatever meathod you are using). I'm also taking
suggestions on features to be added, so if you, or anyone else feels
there are other features that should be added email me about it and
we'll talk about what/how should be added.


On 22:18 Sat 23 Oct     , Ed Grimm wrote:
> 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<b>"</b>?), 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@g.o mailing list
>


--
gentoo-portage-dev@g.o mailing list