[gentoo-user] Merging of config files in /etc

[gentoo-user] Merging of config files in /etc

[Remy Blank]

I thought I knew how configuration files in /etc were updated by portage
until I updated alsa-utils this evening on two computers. Both had 1.0.8
installed, and I updated both to 1.0.9a with:

emerge -uDpv alsa-utils

On the first one, both /etc/init.d/alsasound and /etc/conf.d/alsasound
were updated, so I was asked to run etc-update, I accepted the update,
and that was it.

On the second computer, no update to these files was proposed. While
merging, portage just seemed to assume they were already fine:

--- /etc/
--- /etc/conf.d/
>>> /etc/conf.d/alsasound
--- /etc/modules.d/
>>> /etc/modules.d/alsa
--- /etc/init.d/
>>> /etc/init.d/alsasound

The strange thing is, both files started identical on both computers.
This means that I had lost an update on the second computer, as both
files still had the old content.

Now, I had already noticed that when a package was updated that made
changes to files in /etc, and the changes were merged with etc-update,
and then the same package was re-emerged, then no updates to the file
were done anymore. I had assumed that portage somehow kept track of
etc-update runs. But the situation above doesn't seem to fall in this
category, as there was definitely an update to the files.

So my questions:

 - What are the rules that portage uses to decide if an update to
configuration files in /etc should be proposed to the user (by merging
the file as ._cfg0000_*) or just dropped?

 - How do I make sure that I don't miss an update to configuration
files, like was the case above?

Thank you.
-- Remy


Remove underscore and suffix in reply address for a timely response.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Merging of config files in /etc

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

On Wed, 05 Oct 2005 23:43:34 +0200, Remy Blank wrote:

> On the first one, both /etc/init.d/alsasound and /etc/conf.d/alsasound
> were updated, so I was asked to run etc-update, I accepted the update,
> and that was it.
> 
> On the second computer, no update to these files was proposed.

What is the output from

emerge --info | grep CONFIG

on both computers?


-- 
Neil Bothwick

I thought I saw the light at the end of the tunnel...
but it was just some sod with a torch bringing me more work!

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-user] Re: Merging of config files in /etc

[Remy Blank]

Neil Bothwick wrote:
> On Wed, 05 Oct 2005 23:43:34 +0200, Remy Blank wrote:
> 
> 
>>On the first one, both /etc/init.d/alsasound and /etc/conf.d/alsasound
>>were updated, so I was asked to run etc-update, I accepted the update,
>>and that was it.
>>
>>On the second computer, no update to these files was proposed.
> 
> 
> What is the output from
> 
> emerge --info | grep CONFIG
> 
> on both computers?

On the one that did the update:

CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
/usr/share/config /var/bind /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"

On the one that didn't do the update:

CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env
/usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/share/config /var/qmail/control
/var/www/localhost/htdocs/squirrelmail/config"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"

One more fact: on the second one, I had already emerged
alsa-utils-1.0.9a, and had reverted back to alsa-utils-1.0.8 with a
binary package generated by quickpkg. At that time, I also reverted the
config files.

I played some more with it, and noticed the following:

 1- If I change the mtime of e.g. /etc/conf.d/alsasound to be further in
the past (I set it to July), when I re-emerge alsa-utils-1.0.9a, I get
the ._cfg* file and a notice that I should run etc-update.

 2- Then, if I reject the update, the mtime of the file doesn't change.

 3- If I then re-emerge alsa-utils-1.0.9a, I get *no* ._cfg* file and
*no* notice to run etc-update. But I see that the file's mtime has
changed to the time of the merge, even though its contents haven't
changed. And in /var/db/pkg/media-sound/alsa-utils-1.0.9a/CONTENTS, the
file is registered with the md5 of the *updated* file (i.e. the contents
that should have ended up in the ._cfg* file).

I fail to see why portage should behave differently in 1 and 3 above, if
I assume that it only uses information from the filesystem.

So I'm still confused about the exact rules for proposing an update to
config files, and whether or not portage keeps track of *when* a user
makes changes to them.

-- Remy


Remove underscore and suffix in reply address for a timely response.

-- 
gentoo-user@gentoo.org mailing list