Re: [gentoo-portage-dev] Conary

[Ed Grimm]

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