Daevid Vincent schreef: > Well, it doesn't actually 'solve' the original question, but I did > figure out why superkaramba kept showing up. > > "emerge -Davut world" revealed several plugins related to karamba. So > unmerging ALL of them, finally made the block go away. > > The obnoxious part was that NOT ALL OF THEM showed up in the list > each time.
No, of course not-- emerge -uaDvt world is only going to show those packages that actually have an update available (that's the point of -uD, after all). > I had to keep issuing that command, unmerge the one or two that > showed up, repeat cycle until they were all gone (and there were like > 10 all together). Lame. Sounds like a short-coming of emerge/portage > and dependencies. Don't blame Portage because you didn't do an emerge depclean -p to show packages that formerly depended on an emerged package (in this case karamba) that had been now uninstalled, or an equery depends (super)karamba to see what karamba plugins you had installed. Heck, you could have even done an eix karamba to see which of the various plugins you had actually installed and then just run an emerge -C(av) <plugin1> <plugin2> <etc>. But of course these are (mostly) additional tools, rather than Portage, since this kind of cleanup is not really what Portage is designed to do /per se/ -- and I don't necessarily agree that it /should/ do this kind of cleanup. This whole event is relatively rare (a previously "free" package being included into a major package), and an event of of this sort is significant enough that it should be manually monitored by the admin, rather than just "handled" automatically. It's really not a flaw that you have to find your karamba plugins and unmerge them, then replace them with the new, updated plugins yourself after kde is updated. You are the admin. You are supposed to know the status of your system, and I think Portage behaves quite correctly in going out of its way to make you very aware of changes in status like this, in the event that you might otherwise miss them. Let's face it-- if Portage had just updated superkaramba because you unmerged the previous version, without saying another word, your plugins would be _/broken/_ when you logged into the new KDE (because they were designed for the old "loose" version), you'd be P.O.'d and blaming Portage for _/that/_ (updating without 'fixing' your plugins-- assuming you even knew what was wrong, which you might very well not; it's not like /that/ hasn't happened to all of us one time or another). Almost all of the time if Portage seems not to work, it's because the user is asking it to do something it doesn't do, or phrasing their query incorrectly. I'm not saying that to disrespect you, it's really the truth. Portage is a very complex tool, and in fact works very well, as long as one knows how to use it. But since Portage does in fact know more about the Portage tree than you do (that's its job), "knowing how to use it" sometimes involves trusting it over yourself, and what you (generic "you") /think/ you know. Holly -- gentoo-user@gentoo.org mailing list
