I've made a small patch to portage to be able protect some files from cleaning, but not overwriting. As you'll see, it is at 99% some copy/paste of some CONFIG_PROTECT code. The goal is mainly to be able to keep modules across multiple kernels in /lib/modules. Maybe it can be also useful for other purposes (like keeping this nice icons the day you decide to remove kde, etc.) I know there will probably be some better solutions for modules in the future, using KV slots or things like that, but as a temporary workaround it's okay and can't hurt. If you're interested, I can probably submit a full patch (make.globals default to CLEAN_PROTECT="/lib/modules", bad-english documentation, output in "emerge info", etc.) Reproducible: Always Steps to Reproduce:
Created attachment 14830 [details, diff] portage-2.0.49_pre12--clean_protect.patch The patch is only against "portage.py".
I patched sys-apps/portage-2.0.49 Was ok I will test it later
Created attachment 17830 [details, diff] portage-2.0.49-r4--clean_protect.patch Here is a "not perfect but far better" version of the above patch. Protected files are no more lost by portage. Patch is against emerge and portage.py. I've suggested and explained what this patch does, in a today thread on gentoo-dev: http://article.gmane.org/gmane.linux.gentoo.devel/12257 But I will reexplain it here cause this post was really unreadable: In short, this patch is mainly useful for keeping modules installed in several kernels without manual backup, and without any use $KV slots (which don't work if you want several times the same driver version). It is not really specific to modules though, but so far it's what I've thought it was useful for. - user can define a list of path to protect in his make.conf. CLEAN_PROTECT="/lib/modules" is a good value to protect modules. - when a package is "safely unmerged" (what happens if you install foo/bar-1.0 twice), then files within CLEAN_PROTECT path and that should have been removed are instead protected and added to the new CONTENTS file of foo/bar-1.0. - when you upgrade foo/bar-1.0 to foo/bar-1.1 and have "autoclean" feature, or do a manual "emerge -c", a similar protection happens: protected files from 1.0 are added to the CONTENTS of 1.1, instead of being deleted. (If the package is in several version in several slots, then the protecting pkg will always be the one in the same slot, but in case of "prune". The logic is exactly the one of the clean or prune in emerge.) - when you really want to uninstall foo/bar, "emerge -C" won't take the protection into account. Because the CONTENTS file is up to date with all previous versions installations of the package, the cleanup is total. Hence the day you switch from nvidia to ati, "emerge -C nvidia-kernel" will remove nvidia.o from all kernels modules directories. So far it seems to work for me. I have files from several modules dirs referenced in my alsa-driver and nvidia-kernel CONTENTS files. But there are a few limitations: I've not implemented protection for objects other than files (ie. dirs, symlinks and fifo). Mainly because I don't need it though, but also because it's not clear what I should do in case of broken symlinks for instance (keep them, forget them?). But I can polish it if you think it's an interresting approach. I think it can really improve the way portage install/uninstall modules, which is currently far from the behavior a user may expect. As I see it, CLEAN_PROTECT=/lib/modules could even be a default make.globals value. Ok, that's it, sorry for my verbosity :)
Created attachment 17924 [details] /usr/local/sbin/kernel-packages This small script I developed lists all packages that need to be emerged after installing a new kernel. I use it this way: kernel-packages | xargs emerge -pv
re: comment #4 *You* developed? Come-on, give me some credit! :)
This is what I had in mind: http://marc.theaimsgroup.com/?l=gentoo-dev&m=105455382920883&w=2
My apologies to Georgi. I did not develop the script. I have developed many small scripts and I thought that it was one of them but I was wrong. I will take more care in the future.
Created attachment 18007 [details, diff] portage-2.0.49-r5--clean_protect.patch Update for 2.0.49-r5.
Ping! If you are in the mood for some bugs clean up, I think this one is a good candidate for an "INVALID" or something like that, now that /lib/modules is protected by portage :)
closing per request