I goofed up the etc-update for the new NTP version, so I tried to remerge it, but the config protection is not dumping the ._cfg files. . . --- cfgpro obj /etc/init.d/ntpd --- cfgpro dir /etc/init.d --- cfgpro obj /etc/conf.d/ntpd --- cfgpro dir /etc/conf.d --- !empty dir /usr/share/ntp --- !empty dir /usr/share/doc/ntp-4.1.1b-r4/html/pic --- !empty dir /usr/share/doc/ntp-4.1.1b-r4/html/hints --- !empty dir /usr/share/doc/ntp-4.1.1b-r4/html --- !empty dir /usr/share/doc/ntp-4.1.1b-r4 --- !empty dir /usr/share * Please run etc-update and then read * all the comments in /etc/ntp.conf and * /etc/conf.d/ntpd /doc --- !empty dir /usr/share --- !empty dir /usr/bin --- !empty dir /usr --- !empty dir /etc >>> original instance of package unmerged safely. >>> Regenerating /etc/ld.so.cache... >>> net-misc/ntp-4.1.1b-r4 merged. >>> Recording net-misc/ntp in "world" favorites file... net-misc/ntp selected: none protected: 4.1.1b-r4 omitted: none >>> clean: No packages selected for removal. >>> Regenerating /etc/ld.so.cache... >>> Auto-cleaning packages ... >>> No outdated packages were found on your system. * GNU info directory index is up-to-date. origin root # etc-update Scanning Configuration files... Exiting: No files to work on! origin root #
It's not supposed to. You, in portage's eye, decided to ingore the config, so it will no longer bother you with it. I should probably make this easier to "undo", but in the meantime you can remove the associated files form the listing in /var/cache/edb/config
I see. Thanks for the clarification and work-around. This is interesting to me from a user standpoint because I can only think of two main reasons why one would want to remerge the same version of a package. The first is that for some reason you want to redo the compilation (new use settings perhaps). In this case you would probably find redoing runtime files (i.e. config files) a nuisance. The second case is that for some reason you want to redo the install (critical files got deleted or corrupted, e.g. the config files). In this case you're generally asking for a forceful reinstall, and you want to redo everything as if it had never been done in the first place. With my ntpd install I was after #2. I keep any config file that I modify in version control. Due to a screw up on my part I reverted the ntpd config file back to the old version, instead of checking in the newly merged version from after the update. I'm not sure what you had in mind for the semantics of an "undo" method, but may I suggest that as you devise an iterface for this you attack it from the overall package management standpoint. Think, "Is this 'remerge' a 'rebuild', or a 'reinstall?'", as opposed to "Has this config file been already updated for this version of this package?". I hope that makes sense and doesn't come off as pretentious (I couldn't think of how else to put it). Thanks again, Ian
portage-2.0.47-r1 --noconfmem