On Mon, Jan 06, 2003 at 01:41:08AM -0000, Dhruba Bandopadhyay wrote:
> (1) It is not completely clear which files should be deleted and which
> overwritten.

Those that you didn't alter may probably be overwritten by the newer version,
the others would probably be better left alone, but it's still a good idea to
see the new file, for instance if there are new options in the package.

I'm glad that Portage doesn't touch my configfiles. I should be prompted (as
I am) if there are new configfiles available, and I should be asked if I want
to use them or not. So for me Portage is working fine.

> (3) There are no guidelines on the use of etc-update.   Although,
> documentation does warn that etc-update can be dangerous and must be used
> with care, how is the non-expert user to interpret this advice and how
> much does it really tell him about the use of it?

[... From the FAQ ...]

When updating a package using emerge or ebuild, how do I avoid clobbering my
config files? 

Portage now includes config file management support by default. Type emerge
--help config for more details. The (overly) simple answer is that if a
package installs foo somewhere under /etc, and another foo already exists
there, then the new foo will instead be renamed to ._cfgxxxx_foo in that
directory. A useful tool for examining and updating any protected config
files is etc-update, currently obtained by emerge app-admin/gentoolkit. 

[... From the Portage Manual ...]

*  etc-update : shell script using vim to assist with the merging of /etc
		files (can be dangerous if used incorrectly)

If I am not mistaken, these are the only documents that mention etc-update.
In the Portage Manual is said that it can be dangerous if used incorrectly.
This is true, for instace when etc-update wants to use a new /etc/fstab
(which has occured frequently) and the user blindly accepts, he will be
placed with an illegal /etc/fstab.

However, I do believe that the person in question should be held liable for
his own actions. If he doesn't read what etc-update sais, he shouldn't use
it.


Perhaps a nice feature would be that etc-update sais if the original file has
been altered by the user or not, thus helping the user in his decision wheter
or not to use the new configfile.

> (4) If files are not sorted they stay in their locations indefinitely,
> increase in number and portage warns the user about them on its every use.

Don't tell me you want to disable the warning? There are occasions that ppl
just can't easily use etc-update after an emerge -pu world. For instance
systems that monitor the state of the important files with AIDE: they need to
do a lot more than just accept or decline etc-update proposals.

Or you just don't have the time for your configfiles right now; you surely
don't want to forget that there are new configfiles available? 

> (5) Even if one does see differences in older versions and new ones how
> does one tell if these differences should be preserved or discarded?

Lines with a "-" in front are removed, those with "+" in front are added. So
what you see are the differences between the old and the new configfile.

> (6) If errors or difficulties result how does one rollback?

Not. This could be handy, but also makes the system bigger. Not all ppl want
a Portage-handled rollback (I don't), since they have their own way of doing
things (it's called backupsĂ :).

> I can speak from experience about suffering from problems.  For instance
> today, despite sorting files as carefully as I could, gdm won't load
> anymore and shows no error messages since gdm files were overwritten
> (luckily I use xdm) and also fonts in gnome related applications are now
> huge and different because font locations were changed.  Now, I did look
> at the content of these files before I replaced the older versions but how
> is one to know beforehand what is going to cause issues?

Welcome to the wonderfull world of learning.
 
Wkr,
	Sven Vermeulen
-- 
	Fighting for peace is like fucking for virginity.