| 1 |
On Sunday 28 January 2007 13:16:37 Duncan wrote: |
| 2 |
> OK, either way you did it, you should now be clear of the old kde |
| 3 |
> meta-packages, but you'll still have the actual packages merged. |
| 4 |
> However, once the metapackage is unmerged, you can again run emerge |
| 5 |
> --depclean --pretend, and portage should list all the dependencies of the |
| 6 |
> slot leaf you just removed as stuff it'd now remove. |
| 7 |
|
| 8 |
I didn't really have the patience to read all the way through your post but |
| 9 |
this part does appear to be incorrect. |
| 10 |
|
| 11 |
The world file can only contain package names (neither slots nor versions) so |
| 12 |
removing kde-3.4 while keeping kde-3.5 is not going to change what's in the |
| 13 |
world file. If something in the world file depends on kdelibs-3.5 then |
| 14 |
`emerge --depclean` will not remove kdelibs-3.4 or any other old slots that |
| 15 |
really aren't needed anymore. |
| 16 |
|
| 17 |
Only --prune or --unmerge will do that and both of those currently have the |
| 18 |
downside that they don't check whether it's still needed (as in the case of |
| 19 |
autoconf, automake etc.). Implementing a safer --prune reusing some of the |
| 20 |
code from --depclean (which was improved a lot in portage-2.1.1) has been |
| 21 |
discussed in the past but it isn't done yet. |
| 22 |
|
| 23 |
Fortunately we do know that for any package in the kde categories pruning old |
| 24 |
slots is indeed safe. |
| 25 |
|
| 26 |
-- |
| 27 |
Bo Andresen |
Archives