Occasionally it seems that the SLOT value for ebuilds will change at inappropriate times, which creates unnecessary cluter in the portage database in /var/pkg/db. For instance, I installed KDE when it was at version 3.0.2. At the time, the SLOT values were set to "3". When my system upgraded to 3.0.3, all of the SLOT values were reassigned to "3.0". As a result, every kde-base package I have is in the portage database twice. While this isn't exactly catastrophic, it's certainly unclean, and liable to keep on popping up as people discover that the current SLOT for a package is inadequate for future expansion. Ideally, what I'd LIKE to see is way to specify, in the ebuild or otherwise, that the new SLOT value for an ebuild corresponds to a previous SLOT that ebuild had previously. Perhaps there could be the concept of a "SLOT history" which would stay in the /usr/portage/whatever/package directory, alongside the ebuilds or something. Again, obviously this isn't earth-shatteringly important, but I wanted to submit it here anyway in the hopes that perhaps some bored Gentoo hacker will happen upon it and code something up . . . Also I recognize that any solution to this problem could very well be entirely too complicated and flakey for the potential benefits it brings, but I'm digressing. I wrote a short script to summarize the duplicate SLOTs on your system; there are quite a few on mine right now. I'll attach it to the bug. Thanks for listening!
Created attachment 4005 [details] dups.py Python script to show you the duplicate packages you've got installed, and what SLOTs each of the versions has defined. Just run it without arguments. It relies on qpkg being present (it operates off of the list generated by "qpkg -d -nc").
Actually, the more I think about it, the more I realize that it's probably just a process issue. When accepting ebuilds into the main portage tree, it should really be checked to see that it doesn't do any frivolous SLOT changing. For instance, the KDE packages probably should have stayed at "3", and then if there was ever the need for a "3.1" SLOT, it would just be created then. So doing something programmatically will probably just needlessly complicate things. Perhaps my little program could be expanded to be able to interactively clean out packages that don't belong any more, and then package it up with gentoolkit or something . . . I've done something very similar which could be seen over at http://forums.gentoo.org/viewtopic.php?t=15032 Let me know if anyone thinks something like this could be useful; otherwise I'll be quiet about it for awhile. :)
Forwarding to danarmak, this seems to be a KDE process issue....
I'm not sure it's just limited to KDE. I cleaned out a number of packages that had this mismatch. These are the ones left on my system that seem to be displaying this behavior as well, although I suppose a few of them might be intentional: Package dev-libs/libsigc++: dev-libs/libsigc++-1.1.11 has SLOT '1.2' dev-libs/libsigc++-1.0.4-r2 has SLOT '1.0' ------------------- Package dev-libs/mm: dev-libs/mm-1.2.1 has SLOT '1.2' dev-libs/mm-1.1.3-r1 has SLOT '1' ------------------- Package gnome-base/ORBit2: gnome-base/ORBit2-2.4.0 has SLOT '2' gnome-base/ORBit2-2.4.3 has SLOT '0' ------------------- Package net-p2p/qtella: net-p2p/qtella-0.5.3-r1 has SLOT '0' net-p2p/qtella-0.5.3-r2 has SLOT '3' ------------------- Package net-www/links: net-www/links-2.0 has SLOT '0' net-www/links-2.1_pre2-r2 has SLOT '2'
As for KDE, I _think_ there was a reason for changing from slot 3 to 3.0 at that point. I realized the problem with it, but i nvertheless edcided to do it which means I must have had some reason :-) When I remember it I'll explain it here. In any case we can't do anything much about it now. Going back to "3" would be pointless. As for the generic problem, I think it is indeed the developer's responsibility to change slots only when it's really needed (and when different slots acn live side by side). Marking slots as identical per your suggestion only underlines the fact that they should be the same slot. This would be fighting the symtomps. For the other apps you listed, a separate bug repotr for each might be best. But first we should verify that there were indeed no good reasons for changing the slots in each particular case. Hm...
Is there anything else to be done with this bugreport?
Created attachment 4330 [details] dups2.py Well, I don't know if anything "official" needs to happen with this bug. For myself, I've been meaning to clean up the script I'm attaching now so that it's more suitable for everyday use. It's what I've been using to keep things in order on my box, and it works really well for me, but it's far from perfect. Basically, it'll loop through all packages with more than one installed version. You can select which ones to unmerge by pressing M (for "modify list of unmerges," I suppose). For instance, if there's three versions, it'll list them with 1-3, and if you wanted to unmerge the version numbered 1 and the version numbered 3, you'd type "1 3". To unmerge all of them, "1 2 3". Once you've got some versions in the unmerge list, you can check the package's dependencies by pressing "d," or get a list of all files that would be removed by pressing "f". (The part of the script that lists all the files is pretty messy; that's the main part I'd like to clean up.) Hit "y" to go ahead with the unmerge, though the program will do an "emerge --pretend" first, just to make sure that you know exactly what you're unmerging. So, like I said, I'd like to clean this up and get it a bit more presentable, but I've been meaning to do that for some time now and it hasn't happened (that "works for me" stage of development is always a bit tough like that), so I'm just attaching the version I've got right now. When I get around to cleaning it up, I'll post another attachment here, unless you think it belongs in its own bug (or just somewhere else in general). Thanks! -CJ
Yes, if you want to submit it for inclusion in gentoolkit or anything like that it should be in a new bugreport. I suggest you post it on gentoo-dev and gentoo-user first though, hear what users have to say, it'll help with the polishing too.
Heh, more lists for me to be on. :) Sure, I'll do that once I get the thing cleaned up a bit more. Thanks for the input!
