When updating linux-headers to 2.4.19-r1, the outdated version 2.4.19 was not automatically unmerged, even though 2.4.19-r1 overwrites the 2.4.19 files. Reproducible: Always Steps to Reproduce: 1. emerge linux-headers-2.4.19 2. emerge linux-headers-2.4.19-r1 3. linux-headers-2.4.19 is not removed I manually unmerged linux-headers-2.4.19, and got all "!mtime" messages, proving that 2.4.19-r1 did in fact overwrite all of 2.4.19's files. It might be package specific, or it might be a problem with autoclean.
Seems to work fine here. Puggy
Linux-headers packages are in slots corresponding to the version of the kernel they come from. This obviously doesn't make sense since several versions can't coexist. It will become even worst if at some point portage includes some "update inside slots" feature, because if both a 2.4.18-r1 and 2.4.19 versions are "installed" and a 2.4.18-r2 version is available, then the 2.4.19 files will be overwritten by the 2.4.18-r2 "update". (this is an example from real life, while I was testing portage patch from bug #4698) But this is not a portage bug, only a sys-kernel/linux-headers bug. I think a possible way to make systems go back to an okay state on next update would be: - change all SLOT to "0" in ebuilds - add some code into pkg_postinst() to correct existing installed versions slots. I suggest: for d in ${ROOT}/var/db/pkg/sys-kernel/linux-headers-* do echo "0" > ${d}/SLOT done Yes, it's ugly... but has been successfully tested here. 2.4.19 and 2.4.18-r2 were installed. I've patched 2.4.19-r1, and made the update. Then 2.4.19 and 2.4.18-r1 were unmerged by autoclean, and I now have only one package, in slot 0. A better solution, at portage level, would be some re-sloting directives into portage update files, like there are renamings. I would see them in a separate update files set (to not disturb older portage versions), with, for each package to re-slot, a couple of version numbers and the number of the new slot to affect to versions in this interval. This would be usefull for many packages other than linux-headers (gimp, whose experimental branch has been re-sloted from 1.4 to 2.0, is one that comes to my mind, but I know there have been many others, plus the very old unsloted packages). And here it becomes a portage bug (feature request in fact). PS: I'll add x86-kernel to CC, since it is the only relevant email I know...
> Then 2.4.19 and 2.4.18-r1 were unmerged by autoclean Just to make it clear: 2.4.18-r2, not -r1.
*** This bug has been marked as a duplicate of 29324 ***
bug #29324 and this one have just nothing in common: - bug #29324 is about some misc package being wrongly unmerged for some weird reasons in recent portage version. - this bug is about the linux-header package being slotted whereas it should not. This is an ebuild bug, not dependent on portage (although a clean way to fix it may depend on portage, see bug #27965). Martin, can you explain or reopen please? Thanks.
sorry wrong bug
@Kumba: Following your announcement about 2.4.21 kernel-headers release, I CC you this bug which is also valid for this version. To summarize: There are no reason to slot kernel-headers because nobody needs several version installed at the same time (btw, the best they can do is to completly overwrite each other, and the worst is unpredictable). Proposed fix is to: - on your side, set SLOT=0 in all kernel-headers ebuilds - on portage-dev side, add some kind "slot" command to portage updates as suggested in bug #27965 to allow users going back to a clean system with only one version installed in slot 0. - if the "slot" update command can't be included into portage for some reasons, then you can also fix it from kernel-headers ebuilds with the quick and dirty hack in comment #2.
I changed the SLOT Value in the 2.4.21 and 2.4.22 ebuilds to 0 from ${OKV}. I don't want to touch the 2.4.19 ebuilds w/o someone testing the 2.4.21 changes first. Especially since I re-wrote the 2.4.21 ebuild, I feel more responsible for it's maintainence than the older 2.4.19 ebuild. I tested this change on my sparc64 box too, by changing SLOT to 0, merging it, unmerging the older 2.4.19 and 2.4.22 (must've been some test) versions, and re-merged 2.4.21 again to be safe. Nothing looks to have broken, which is a good thing. Also, this really isn't a portage issue, and since I released 2.4.21 into the wild, I'll take over this bug. Although the idea about the SLOT tool might be useful to file as a separate bug assigned to dev-portage (they'll love you if you include code to partially implement such a tool, btw). Test 2.4.21 out some, and since it will hopefully replace 2.4.19 in a couple of weeks, might just roll out this SLOT change when 2.4.21 goes stable. Maybe even add a small notice to pkg_postinst() about the SLOT change in the future.
> I changed the SLOT Value in the 2.4.21 and 2.4.22 ebuilds to 0 Thanks for having taken this report into account. > Also, this really isn't a portage issue No, sure, but the easiest fix for the users go through a portage enhancement. I've already proposed a patch quite some time ago in bug #27965 that implements this "slot" update command. When I've done this, one of my test was to add in a portage update file the following command: "slot sys-kernel/linux-headers sys-kernel/linux-headers 0" Then, after portage ran the update, all my old kernel headers entries in the db were reslotted to 0, and the next autoclean removed the outdated ones automatically. That's why I think this is really the easiest way to clean users' pkg db, because it doesn't require anything from the user. Now, this patch never got into portage (don't know why, I had no feedback at all)... So your suggestion about an einfo to tell the user to manually do the job sounds good. I would see something like: * If you are upgrading from a version prior to 2.4.21, then run: * /usr/portage/sys-kernel/linux-headers/files/clean-headers.sh (I think a small shell script would be usefull, because from my experience on forums, most users don't know how to unmerge a particular version of a package. I will attach such a script, feel free to accept/modify/ignore it.)
Created attachment 19661 [details] files/clean-headers.sh
*** Bug 32197 has been marked as a duplicate of this bug. ***
linux-headers-2.4.21 and 2.4.22 have been corrected. I've corrected mips-headers with this same slot issue. As for 2.4.19, plasmaroo I believe will take care of that.
All linux-headers ebuilds should now have SLOT="0"...
All done, resolving as FIXED.
