When a version specific savedconfig exists and you update x11-wm/dwm with USE=savedconfig, the ebuild deletes the old version then reports that no config exists, much to the ire of the user who poured time into customizing the file that emerge deleted. The ebuild should not delete savedconfig. Reproducible: Always Steps to Reproduce: 1.Have a version specific savedconfig for x11-wm/dwm and USE=savedconfig 2.Update dwm with emerge 3.Emerge deletes savedconfig with no warning or input Actual Results: Lose savedconfig. Expected Results: Not touched savedconfig, potentially even copied over to a savedconfig for the new version and attempted an emerge with the old config.
It's nothing to do with x11-wm/dwm, really - the savedconfig.eclass uses $PF, maybe in error.
the eclass doesn't delete anything. it also uses $PF by default on purpose, but i probably could be convinced to have it use $P instead. not that that would change the behavior you speak of.
I guess we could add a variable that's similar to CONFIG_PROTECT, that would prevent files in specific directories from being unmerged. As it is, we have behavior like this hardcoded for /lib/modules, and the default COLLISION_IGNORE="/lib/modules" setting is used to ignore file collisions that result from this behavior. How about if we call the new variable UNINSTALL_EXCLUDE, and make it default to UNINSTALL_EXCLUDE="/lib/modules /etc/portage/savedconfig". Would you want to ignore file collisions by default in /etc/portage/savedconfig? If so, we could add it to the default COLLISION_IGNORE setting.
what we want here is to leave the files behind only if they're modified. i.e. we want something like ORPHANS_UNINSTALL_EXCLUDE=/etc/portage/savedconfig/. i don't think this dir should be special in terms of collision handling ... nothing would own it, so the file would get clobbered ...
Now I'm thinking the problem is that the user has CONFIG_PROTECT_MASK="/etc/portage" set, because FEATURES=unmerge-orphans does not apply to CONFIG_PROTECTed packages that have been modified since they were installed.
thomasward: can you post `emerge --info --verbose` ? things seem to work for me as expected: # emerge ~dropbear-0.53.1 # printf '#define foo\n' >> /etc/portage/savedconfig/net-misc/dropbear-0.53.1 # emerge ~dropbear-2011.54 --- !mtime obj /etc/portage/savedconfig/net-misc/dropbear-0.53.1 < /etc/portage/savedconfig/net-misc/dropbear-0.53.1 is left behind >
Created attachment 297607 [details] emerge --info --verbose output Here's my emerge --info --verbose
and try running my example series of dropbear commands and post the output as an attachment that you see ?
Created attachment 297809 [details] emerged dropbear, edited config, updated So updating dropbear did not obliterate the previous savedconfig. it does still occur for x11-wm/dwm, and I am not the only person experiencing this behavior: http://forums.gentoo.org/viewtopic-t-704481-highlight-dwm+savedconfig.html
then show the log of dwm. it doesn't do it for me there either: # emerge -v '<dwm-6' # printf '#define foo\n' >> /etc/portage/savedconfig/x11-wm/dwm-5.9 # emerge -v dwm < /etc/portage/savedconfig/x11-wm/dwm-5.9 still exists >
Created attachment 297841 [details] Emerge log of steps that remove dwm savedconfig I can reproduce this bug every single time. Here are the steps: 1) have a dwm-5.9 in portage's savedconfig 2) have USE=savedconfig 3) install x11-wm/dwm-5.9: emerge ~dwm-5.9 4) Update dwm (will update to dwm-6.0 at the moment: emerge -u dwm This leaves the user with a default savedconfig for dwm-6.0 and a deleted savedconfig for dwm-5.9 without any user input.
Comment on attachment 297841 [details] Emerge log of steps that remove dwm savedconfig if you don't edit the savedconfig, then it *should* get removed automatically. it only stays behind if you modify it. thus your log (which shows you did not edit the 5.9 config file) is showing expected behavior and not a bug.
Created attachment 297851 [details] Emerge deletes savedconfig after re-emerge of program followed by update I have finally narrowed down a reproducible test case that shows portage deletes a modified savedconfig (you can see it through the log I attached but here's the summary) 1) Un-emerge dwm and delete any savedconfig for x11-wm/dwm 2) Set USE=savedconfig in /etc/make.conf 3) emerge ~dwm-5.9 At this stage, portage generates a default savedconfig 4) Modify savedconfig (I used vim in the log) Now since this is dwm, I must re-emerge dwm so I can have my changes actually take effect 5) emerge ~dwm-5.9 Now I have my modified dwm with a savedconfig I changed. An update hits the portage tree: 6) emerge -u dwm Portage deletes dwm-5.9 savedconfig and puts in a generic dwm-6 savedconfig, since it thinks the one is brand new. Why? I suppose since it was unmodified since the last emerge. Portage must check to see if it is modified since the last emerge. If it's not, then it deletes it. If it is, it doesn't delete it.
(In reply to comment #13) > 6) emerge -u dwm > Portage deletes dwm-5.9 savedconfig and puts in a generic dwm-6 savedconfig, > since it thinks the one is brand new. Why? I suppose since it was unmodified > since the last emerge. Portage must check to see if it is modified since the > last emerge. If it's not, then it deletes it. If it is, it doesn't delete it. In order to avoid that, savedconfig.eclass could to something like this in pkg_postinst: find "${ROOT}"/etc/portage/savedconfig/${CATEGORY}/${PF} | xargs touch
I don't think that would delete an unchanged savedconfig which *should* happen, right? How about upon removing x11-wm/dwm, portage diff's the default savedconfig the ebuild installs with the savedconfig in /etc/portage/savedconfig/ ? If any change exists, then keep it, else delete it. Sound reasonable?
this is because during the re-emerge, the modified version is integrated into the build and then considered the new baseline. so it installs that, and the contents match that of what was installed, and the upgrade automatically drops the now-considered-unmodified version. the eclass could save/restore/install the unmodified config, but then every rebuild would incur an etc-update. i'd consider this sub-optimal, but maybe people would prefer that. to avoid that, the eclass would have to add a pkg_preinst() hook to automatically migrate the user-modified version over the default config so that it both shows up as modified and doesn't incur the etc-update. i don't think `touch` would help as it would leave behind unmodified files. the current system is nice in that it doesn't leave behind cruft.
the pkg_{pre,post}inst hooks appear to be unavoidable. portage will do "trivial" merges by considering things which are comments in one language (like shell scripts) as trivial even though in the actual language, these are not comments. simple example being "#define FOO". i'm not saying this is a failing in portage -- the whole savedconfig setup is kind of a hack. another option might be to have save_config save the files in one location and make the user manually copy them to another. downside obviously being that this can be a bit confusing for users trying to tweak things.
i've coded up examples for the various methods, and they all suck. i'm just going to go with the least sucky in terms of maintenance: if you have USE=savedconfig, then the eclass will do as Zac suggested and touch all the files in pkg_postinst. this will leave files to rot over time, but they're small enough to not worry about for now, and it'll only affect the USE=savedconfig people who are presumably editing the files anyways.
http://sources.gentoo.org/eclass/savedconfig.eclass?r1=1.19&r2=1.20
This issue is still present for me. I'm not sure if the commit in comment #19 was supposed to fix it or if it's intended behaviour. I upgraded linux-firmware-20120719 to linux-firmware-20120924. The savedconfig for linux-firmware-20120719 was deleted and a new one (without my edits) was created for linux-firmware-20120924. Is there any way to avoid this issue?
(In reply to comment #20) > This issue is still present for me. I'm not sure if the commit in comment > #19 was supposed to fix it or if it's intended behaviour. Yes, it was. > I upgraded linux-firmware-20120719 to linux-firmware-20120924. The > savedconfig for linux-firmware-20120719 was deleted and a new one (without > my edits) was created for linux-firmware-20120924. > > Is there any way to avoid this issue? Check your emerge --info and make sure that CONFIG_PROTECT contains /etc, and CONFIG_PROTECT_MASK does NOT contain /etc/portage. (In reply to comment #3) > I guess we could add a variable that's similar to CONFIG_PROTECT, that would > prevent files in specific directories from being unmerged. As it is, we have > behavior like this hardcoded for /lib/modules, and the default > COLLISION_IGNORE="/lib/modules" setting is used to ignore file collisions > that result from this behavior. Recent versions of portage (2.1.11*) support an UNINSTALL_IGNORE which defaults to UNINSTALL_IGNORE="/lib/modules/*". So, you can use a setting like this to protect /etc/portage/savedconfig: UNINSTALL_IGNORE="${UNINSTALL_IGNORE} /etc/portage/savedconfig/*"
(In reply to comment #21) > Recent versions of portage (2.1.11*) support an UNINSTALL_IGNORE which > defaults to UNINSTALL_IGNORE="/lib/modules/*". So, you can use a setting > like this to protect /etc/portage/savedconfig: > > UNINSTALL_IGNORE="${UNINSTALL_IGNORE} /etc/portage/savedconfig/*" I added that line to make.conf and it appears to be working. The previous savedconfig is left behind and a new one (without edits) is created. This is definitely better than the previous behaviour. Thanks for the help.
Portage still deletes the savedconfig of the unmerged version by default. It has annoyed me a couple times so far as I had to go restore the config out of a backup to transfer it to the new package version. I know I could name it without the version part but I like to keep them separate so that the old config doesn't cause a build failure if its format isn't compatible, then I can manually adapt it and re-merge. It would be nice if the behavior described in comment #21 of UNINSTALL_IGNORE were the default. I checked that CONFIG_PROTECT{,_MASK} are set as they should but the savedconfig is still deleted.
