try: rm /etc/freenet.conf emerge freenet emerge freenet Now you will have a /etc/._cfg0000_freenet.conf - even though you never touched /etc/freenet.conf. Emerge should be able to see that I did not change freenet.conf and should overwrite it if the contents' md5sum matches the md5sum at install time. If the md5sum does not match then I have probably altered the file and it should not touch it.
What version of Portage are you using?
How do I see that?
Is this what you want? $ emerge --version Portage 2.0.11
Now I am using 2.0.25. The bug is still there. It seems the freenet.conf changes from installation to installation. (listenPort and storeSize). But emerge should make an MD5-sum of the config after install and keep this. If a config-file is to be updated then if the MD5-sum matches it should just be overwritten. Otherwise the current behaviour is probably correct (as the user may have altered the file). There is a tricky part if another package has changed the config file.
*** Bug 6375 has been marked as a duplicate of this bug. ***
*** Bug 10255 has been marked as a duplicate of this bug. ***
*** Bug 11134 has been marked as a duplicate of this bug. ***
Nick, I think this was fixed with the new md5 config stuff.
Nope. The example with freenet still gives a /etc/._cfg0000_freenet.conf (though now you have to emerge the ebuild as freenet has become masked
Then the file have to change. Check /var/cache/edb/config. I have tested this at some stage with baselayout (lot of files, many change some times) and had given feedback/bugreports back to Daniel.
Martin: Could you please try with freenet too? It might be an error on my system. rm /etc/freenet.conf /etc/._cfg*freenet.conf emerge freenet emerge freenet
As I'm also interested this, I just tried emerging freenet twice. I can confirm that in Portage 2.0.45, I still get /etc/._cfg0000_freenet.conf the second time.
Probably because freenet updates the mtime on this file? Or tweaks it regularly in some way?
For security reasons Freenet does not use one dedicated freenet port (i.e. there is no freenet in /etc/services). Instead it uses any port chosen by the administrator. When you install freenet it automatically chooses a random port. So if you remove freenet and install it again you will probably have another port. This port is mentioned in freenet.conf. My guess is that part of the install procedure is to alter this port in the freenet.conf. It _is_ done before starting the freenet server, and I have never seen the freenet server change /etc/freenet.conf. Here is my suggestion for solving the issue: * Install freenet * MD5sum all files installed by freenet and remember these * Before re-install: - Remove all files owned by freenet that has the remembered MD5sums * Install as normal
I now think this is nothing to do with freenet. I just did an emerge system and ended up with 44 config files to sort out. But most of them were files I had never edited. This is with Portage 2.0.46-r4.
Created attachment 7997 [details, diff] portage-2.0.46-r11.ebuild.patch This patch implements a new feature for Portage which alters the way it handles config-protected files. This patch is for the ebuild. The full patch is in the next attachment. Briefly, it adds the following: * Alter config file handling (keeping current versions). * Auto-migrate ._cfg files to new structure during Portage upgrade. * Auto-replace unchanged config files when new versions are installed. * New FEATURE config_automerge tells Portage to automatically merge config file changes into the current file. Finding a conflict aborts this merge. * Implement etc-update in python. * Fully implement 'menu' mode in etc-update (using dialog). * Support 3-way diffs/merges in etc-update. More details on gentoo-dev@gentoo.org.
Created attachment 7998 [details] files/config-automerge-2.0.46-r11.patch.bz2 See previous.
Created attachment 7999 [details] files/config-automerge-2.0.46-r11.patch.bz2 Gah. I left the 'echo's in migrate-config, which would cause it to not actually do anything. This fixes it.
Created attachment 8037 [details, diff] portage-2.0.46-r12.ebuild.patch New version of the config_automerge patch. The following changes were made: * Updated to portage-2.0.46-r12 * Removed debug message related to config_automerge feature. * Added ability for getconfig to handle escaped quote characters within quoted string. * Fixed bug which caused config_protect.need_updating not to find all files which need to be updated. * Fixed bug referencing grabdict instead of portage.grabdict when installing config file which has no recorded versions. * Added check for automerge when re-merging same version (handles the case where the user merges, decides to enable automerge, and then re-merges). * Fixed several syntax errors in the ebuild (note to self: always test after making changes right before releasing, no matter how minor).
Created attachment 8038 [details] files/config-automerge-2.0.46-r12.patch.bz2 See previous.
I would want to see that patch to be officially merged with portage ASAP. Hello portage maintainer?
This patch is _way_ too big for me to consider presently. We're reorganizing, and have places and code for 3-way and rcs merges code and in development/testing, respectively. If you want me to consider this patch, please break it down and explain why you are changing so much code. Verbose is good.
Thanks for the response. Most of the size has to do with moving portage.py to portage/__init__.py, in order to allow modularization of the portage code. I can remove this and move the new config management code into portage.py, which would reduce the size of the patch. I would, however, recommend breaking up the portage.py file into modules at some point; it would make it a lot easier to grok and thus maintain. I'll try to get this done before I go out of town at the end of the week; if I don't manage it, though, I'll submit something in a couple weeks.
*** Bug 14666 has been marked as a duplicate of this bug. ***
*** Bug 14730 has been marked as a duplicate of this bug. ***
What you need is for portage to store the md5 checksums of each file in /etc in another dir (eg /etc/md5s) so you still have the md5 checksum of each file. Then all you need is for etc-update to get a bit more intelligent and clean up the md5 checksums as you update them.
Created attachment 8768 [details, diff] files/config-automerge-2.0.47-r4.patch As promised, here's a newer, smaller version of the automerge patch. This is built to run against 2.0.47-r4. Changes (off the top of my head) from the previous patch: * Moved portage/__init__.py back up to portage.py and integrated config_protect.py. I still feel that the portage python module should be broken up at some point. * Changed %orig in etc-update.conf to %ancestor, and added backwards compatiblity for %file1,%file2,%orig directives. This should allow etc-update to be run after the portage upgrade. * Removed the conf-embedded-quotes fix to another patch (bug #14215). * Completely rewrote migrate-config as a python script which now archives all existing unchanged copies of config files in addition to moving ._cfg files. * Reformatted make.conf FEATURES help text to improve readability. As requested, I'll also go over each of the files in the patch and why the changes are there. * bin/emerge The only change here is the scan for config files to be updated, which gets delegated to the appropriate function in portage. One drawback to this approach is that it doesn't report the numbers by directory, but I don't feel this is a significant issue. * bin/emergehelp.py Changes here are simply help text changes to reflect the new features and structure. * bin/etc-update This is one of the two most significant changes. etc-update has been completely rewritten as a python script, and support for dialog has been fully implemented using the pythondialog module. I'm not completely happy with pythondialog's API, but I feel that it's a good starting point, and I plan to improve it some time soon if this patch is accepted. The reason for the rewrite is twofold. Clearly the new structure required changes to etc-update, and implementing it in python made the most sense, since most of the functionality already exists (with this patch) in portage.py. Also, having it in python is nice from standpoint of maintainability, since it's easier to get it to do the right thing and because it obviates the need for hacks (such as the current one had) for reading config files, etc. * bin/migrate-config The sole purpose of this new script is to create the new cache/edb/config_protect hierarchy and to move all ._cfg files over to it. It's a one time thing, and could be run by the ebuild if desired. * cnf/etc-update.conf A few changes here: 1. Change mode variable semantics to use text/menu instead of 0/1 for clarity. 2. Change diff expansion variable naming from file1/file2 to current/new to improve clarity and to bring them inline with the merge variable naming. 3. Change merge variable naming from orig/new to ancestor/current/new to support concept of an "ancestor" file for 3-way merges and to improve clarity. (What does "orig" mean when you have two "original" files?) 4. Added help text to explain new 3-way diff/merging as well as additional sample diff/merge commands. Note that while I've changed the mode and diff/merge naming, I maintained backwards compatibility to the old values in order to allow etc-update to run correctly after the initial upgrade of portage. * cnf/make.conf * cnf/make.conf.alpha * cnf/make.conf.arm * cnf/make.conf.hppa * cnf/make.conf.mips * cnf/make.conf.ppc * cnf/make.conf.sparc Two changes here. The first, which is minor, simply adds an explanation for the config_automerge feature. The larger change is a reformatting of the FEATURES help text, which I feel greatly improves the readability of the explanation of each feature. * man/etc-update.1 Change the AUTHORS attribution to reflect the rewrite of etc-update. * man/make.conf.5 Added text to explain the new config_automerge feature. * pym/portage.py And the largest change of all. I'll try to break it up a bit. 1. Removed all references to cfgfiledict, since this data is no longer relevant with the new cache/edb/config_protect hierarchy. 2. Removed all handling of ._cfg files (again, no longer relevant). 3. Since mydest gets rewritten by the call to add_new_version() and since add_new_version() handles all file copying and timestamps, skip moving the file but also skips setting the timestamp on the destination (hence the 'else -> elif not cfgprot' change). 4. Add new class 'config_file' which handles all logic dealing with the config_protect backup hierarchy, as well as a support function for finding all config files in need of etc-updating. Also note that I'm not providing a patch to the ebuild this time, since I pulled out the auto-running of migrate-config (although the way it's written now, portage will complain if called upon to do anything with config files before migrate-config is run; it does so with a message to run the script and a pointer to its location). However, the diff I'm using against the 2.0.47-r4 ebuild is: --- portage-2.0.47-r4.ebuild.orig 2003-02-25 18:19:05.000000000 -0800 +++ portage-2.0.47-r4.ebuild 2003-02-26 23:02:45.000000000 -0800 @@ -16,6 +16,8 @@ LICENSE="GPL-2" RDEPEND="!build? ( >=sys-apps/fileutils-4.1.8 dev-python/python-fchksum >=dev-lang/python-2.2.1 sys-apps/debianutils >=sys-apps/bash-2.05a )" +inherit eutils + get_portver() { python -c "import portage,string; print string.join(portage.pkgsplit(portage.best(portage.db[\"${ROOT}\"][\"vartree\"].dbapi.match(\"sys-apps/portage\"))))" } @@ -31,6 +33,11 @@ cd ${WORKDIR} echo tar xjf ${DISTDIR}/${PF}.tar.bz2 tar xjf ${DISTDIR}/${PF}.tar.bz2 || die "No portage tarball in distfiles." + ( + cd ${PF} + epatch ${FILESDIR}/conf-escaped-quotes.patch + epatch ${FILESDIR}/config-automerge-${PVR}.patch + ) #get_portver > ${WORKDIR}/previous-version } Feel free to use this if you'd like to try the patch out. Note that the conf-escaped-quotes patch is available as an attachment to http://bugs.gentoo.org/show_bug.cgi?id=14215. And that's it. Hopefully that's a good enough explanation of what's going on, but please let me know if you'd like clarification on any aspect of the patch or any changes made by it. I would also (if that's what it'd take) be willing to implement this functionality as a selectable feature (config_backup, perhaps) so that portage would would only use the new config backup hierarchy if it were enabled, but would default to using the old ._cfg_* handling.
Created attachment 8773 [details, diff] files/config-automerge-2.0.47-r4.patch Just a quick replacement for the previous patch. I left some debug code in migrate-config which caused it to abort before it completed its full run. This is fixed.
Portage is now onto 2.0.47-r8 (for ~x86). Is there any hope for this patch to make it into portage at some point during the future or is this feature considered unecessary? (It is time saving.)
Hows it coming with this feature? It would be really nice - so I didn't have to manually find out what etc-files I haven't changed since install :)
This was fixed a long time ago. Close this bug as FIXED.
No its not. Portage still doesn't replace unmodified config files.
i'm in favor of this feature. portage doesn't seem to currently do this at all.
dispatch-conf...
Jason Stubbs writes about dispatch-conf which is a part of portage. After configuring it according to http://gentoo-wiki.com/TIP_dispatch-conf it seems you are able to just run dispatch-conf. I have tried it on freenet, and that now works corrrectly.
*** Bug 23345 has been marked as a duplicate of this bug. ***
*** Bug 97339 has been marked as a duplicate of this bug. ***
