Hi! It should be moved by now, I think.
Anyways, I understand that removing pieces of KDE and the parts of it is possible and not all that difficult. I'm not really worried about how to do it, but thanks for the info anyway! :) I was just wondering why the metapackages only seemed like a one way street. They're simple to install, but useless for anything else because of a bug (?) that was inhereted from portage. From what everybody is saying, I almost get the impression that it's going to stay that way. Is that true or is anything going on to take care of that? On 2/27/06, Duncan <[EMAIL PROTECTED]> wrote: > Mike Myers posted <[EMAIL PROTECTED]>, excerpted below, on Sun, > 26 Feb 2006 17:05:57 -0600: > > > Do you know if there's a way or going to be a way to handle the split > > ebuilds so that reemerging or unemerging a split ebuild will reemerge or > > unemerge the corresponding packages? It seems like the ebuilds are only > > intended to make installing kde easier, which they do, but it doesn't > > make handle uninstalling or reinstalling a split ebuild very easy at > > all. > > As others have said it's a technical/portage issue. > > Unmerging a package always leaves dependencies behind. To clean those > up, emerge -NuD world (to ensure use dependencies are uptodate), emerge -p > depclean (to get a list of what it thinks is unneeded), fix anything on > that list you know to be needed (add it to world), then either unmerge > individually (as I do, even then, ensuring I haven't missed adding > something to world that I should have, verifying what each package does > and thinking about whether I actually do need it as I go) or if you > prefer, use the depclean without the -p, then, finally, do a > revdep-rebuild (first -p it, of course) to catch any dependencies that > still might have slipped thru and need rebuilt. > > Upgrading is a bit more sensitive. However, with things like KDE > upgrades, I'll often use the --prune parameter on emerge, combined with -p > first of course. Then again, I unmerge manually as necessary. One other > method I've used is to do an equery list of kde packages, then grep it > for the version I want to unmerge, to get a list of old packages. So an > upgrade from 3.4 to 3.5 I'd grep for 3.4. Finally, when you've unmerged > most old KDE packages, take a look at the old /usr/kde/<ver> dir and see > what's left there, then do equery belongs <file> with what's left, to > figure out the packages they belong to. Anything left over that doesn't > belong to a package should be deletable, or if you prefer to be safe, move > it to a backup dir for a month or so first, so you can restore it if > necessary. Again, after unmerging stuff, a revdep-rebuild is recommended. > > As others said, please move futher discussion to either user or desktop. > I don't look at user, but I'm a regular over in desktop, where KDE > questions are happily answered, as it's certainly part of desktop. > > -- > Duncan - List replies preferred. No HTML msgs. > "Every nonfree program has a lord, a master -- > and if you use the program, he is your master." Richard Stallman in > http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html > > > -- > gentoo-dev@gentoo.org mailing list > > -- Mike Myers [EMAIL PROTECTED] http://www.yaay.us -- gentoo-user@gentoo.org mailing list
