On Tuesday 06 February 2007, Dale wrote: > I don't understand portage and ebuilds well enough to do that. How > about this. Is there a way to just tell emerge to emerge each > separate package and get rid of kde-meta?
kde-meta is, well, as meta package. All it does is tell portage to emerge all the dependencies, and that turns out to be all 300 individual kde ebuilds. kdebase-meta is the same thing on a smaller scale and only for the basic stuff. You could 'emerge -avC kde-meta' and all that would happen is the -meta package gets removed, leaving the deps in place. However, they aren't in world so your next 'emerge --depclean' will want to remove them. Few people actually use all of KDE, so a good compromise is to figure out what you actually do use and emerge just those ebuilds Have you read the kde split-ebuilds HOWTO at gentoo.org/doc lately? It's all in there, but it's a lot of info so it's useful to refresh the old memory every now and again > I don't know, equery list > kde then poke them in one by one. Would that let it leave kate and > kdelibs where it is without masking all of kde? I just tried this test: masked kate-3.5.6 unmerged kdebase-meta emerge -pD world and it went crazy with blockers. Portage wanted to emerge kdebase-3.5.5 (not the -meta) one and that was bloked by all the kdebase packages at version 3.5.6. So it would seem there are some hard coded blocks in place, which is sensible as mixing KDE app and lib versions willy-nilly is probably not a good idea... > Thanks for the reply though. At least I can open the file and read > it and it is not just me having this problem. alan -- Optimists say the glass is half full, Pessimists say the glass is half empty, Developers say wtf is the glass twice as big as it needs to be? Alan McKinnon alan at linuxholdings dot co dot za +27 82, double three seven, one nine three five -- gentoo-user@gentoo.org mailing list
