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 ._cfg_*) 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
