1 |
Hi! |
2 |
|
3 |
It should be moved by now, I think. |
4 |
|
5 |
Anyways, I understand that removing pieces of KDE and the parts of it |
6 |
is possible and not all that difficult. I'm not really worried about |
7 |
how to do it, but thanks for the info anyway! :) |
8 |
|
9 |
I was just wondering why the metapackages only seemed like a one way |
10 |
street. They're simple to install, but useless for anything else |
11 |
because of a bug (?) that was inhereted from portage. From what |
12 |
everybody is saying, I almost get the impression that it's going to |
13 |
stay that way. Is that true or is anything going on to take care of |
14 |
that? |
15 |
|
16 |
On 2/27/06, Duncan <1i5t5.duncan@×××.net> wrote: |
17 |
> Mike Myers posted <44023455.3040906@×××××.com>, excerpted below, on Sun, |
18 |
> 26 Feb 2006 17:05:57 -0600: |
19 |
> |
20 |
> > Do you know if there's a way or going to be a way to handle the split |
21 |
> > ebuilds so that reemerging or unemerging a split ebuild will reemerge or |
22 |
> > unemerge the corresponding packages? It seems like the ebuilds are only |
23 |
> > intended to make installing kde easier, which they do, but it doesn't |
24 |
> > make handle uninstalling or reinstalling a split ebuild very easy at |
25 |
> > all. |
26 |
> |
27 |
> As others have said it's a technical/portage issue. |
28 |
> |
29 |
> Unmerging a package always leaves dependencies behind. To clean those |
30 |
> up, emerge -NuD world (to ensure use dependencies are uptodate), emerge -p |
31 |
> depclean (to get a list of what it thinks is unneeded), fix anything on |
32 |
> that list you know to be needed (add it to world), then either unmerge |
33 |
> individually (as I do, even then, ensuring I haven't missed adding |
34 |
> something to world that I should have, verifying what each package does |
35 |
> and thinking about whether I actually do need it as I go) or if you |
36 |
> prefer, use the depclean without the -p, then, finally, do a |
37 |
> revdep-rebuild (first -p it, of course) to catch any dependencies that |
38 |
> still might have slipped thru and need rebuilt. |
39 |
> |
40 |
> Upgrading is a bit more sensitive. However, with things like KDE |
41 |
> upgrades, I'll often use the --prune parameter on emerge, combined with -p |
42 |
> first of course. Then again, I unmerge manually as necessary. One other |
43 |
> method I've used is to do an equery list of kde packages, then grep it |
44 |
> for the version I want to unmerge, to get a list of old packages. So an |
45 |
> upgrade from 3.4 to 3.5 I'd grep for 3.4. Finally, when you've unmerged |
46 |
> most old KDE packages, take a look at the old /usr/kde/<ver> dir and see |
47 |
> what's left there, then do equery belongs <file> with what's left, to |
48 |
> figure out the packages they belong to. Anything left over that doesn't |
49 |
> belong to a package should be deletable, or if you prefer to be safe, move |
50 |
> it to a backup dir for a month or so first, so you can restore it if |
51 |
> necessary. Again, after unmerging stuff, a revdep-rebuild is recommended. |
52 |
> |
53 |
> As others said, please move futher discussion to either user or desktop. |
54 |
> I don't look at user, but I'm a regular over in desktop, where KDE |
55 |
> questions are happily answered, as it's certainly part of desktop. |
56 |
> |
57 |
> -- |
58 |
> Duncan - List replies preferred. No HTML msgs. |
59 |
> "Every nonfree program has a lord, a master -- |
60 |
> and if you use the program, he is your master." Richard Stallman in |
61 |
> http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
62 |
> |
63 |
> |
64 |
> -- |
65 |
> gentoo-dev@g.o mailing list |
66 |
> |
67 |
> |
68 |
|
69 |
|
70 |
-- |
71 |
Mike Myers |
72 |
mike@××××.us |
73 |
http://www.yaay.us |
74 |
|
75 |
-- |
76 |
gentoo-user@g.o mailing list |