As modprobe will in future releases ignore every file not suffixed ".conf" app-emulation/kqemu should install its file as /etc/modprobe.d/kqemu.conf instead of /etc/modprobe.d/kqemu. If user has made no changes to this file it should be enough to change the creating line, and portage unmerge-orphans should do the rest. See Bug #274942
Created attachment 195646 [details, diff] Patch for kqemu-1.4.0_pre1 ebuild to create /etc/modprobe.d/kqemu.conf Patch renames /etc/modprobe.d/kqemu to /etc/modprobe.d/kqemu.conf, or moves /etc/modules.d/kqemu to /etc/modprobe.d/kqemu.conf. New version of config file created as /etc/modprobe.d/kqemu.conf .
(In reply to comment #1) > > Patch renames /etc/modprobe.d/kqemu to /etc/modprobe.d/kqemu.conf, or moves > /etc/modules.d/kqemu to /etc/modprobe.d/kqemu.conf. New version of config file > created as /etc/modprobe.d/kqemu.conf . > As this file is not supposed to be changed by users, I think unmerge-orphans is enough to remove the old file, so the pkg_preinst is not necessary.
Should all ebuilds be changed to install the new filename or only kqemu-1.4.0_pre1. I also can do the commit if you don't have the time.
(In reply to comment #2) > As this file is not supposed to be changed by users, I think unmerge-orphans > is enough to remove the old file, so the pkg_preinst is not necessary. unmerge-orphans doesn't remove files in CONFIG_PROTECT, according to manual. Bug #275910 gives a real-world example where a simple upgrade doesn't work.
(In reply to comment #4) > > unmerge-orphans doesn't remove files in CONFIG_PROTECT, according to manual. > Bug #275910 gives a real-world example where a simple upgrade doesn't work. > You are right, unmerge-orphans is for files outside CONFIG_PROTECT that now can be removed even if their mtime or content is changed. Then I have no idea how that feature is called, but here the old /etc/modprobe.d/kqemu is automatically removed by portage, as I did not change this file.
(In reply to comment #5) > Then I have no idea how that feature is called, but here the old > /etc/modprobe.d/kqemu is automatically removed by portage, as I did not > change this file. OK, I assume the "not changed" part is checked using checksum and probably mtime as well. Still, two issues remain. One is different package managers. While portage might behave that way, do others as well? Does pms say anything here? The other is the fact that although I agree that most users should not need to change their kqemu.conf, it is in /etc, it's not masked from config protection, and it does not contain a bug fat warning. So users might be justified in expecting that they may edit this file without breaking future upgrades.
Is there a good reason not to apply the patch from Ian and close this thing here?
Commited your patch to kqemu-1.4.0_pre1-r1.
