| 1 |
On Monday 29 January 2007 13:03:28 Duncan wrote: |
| 2 |
> While I knew that world doesn't contain slots |
| 3 |
> or versions, I thought (and believe it works that way in ~portage, but it |
| 4 |
> may not have reached stable yet, and I could be wrong) that unmerging the |
| 5 |
> metapackage would then release the dependency on the other stuff in that |
| 6 |
> slot. For KDE monolithics, for instance, I believe(d) that while |
| 7 |
> old kdelibs won't be unmerged immediately as it isdepended on by |
| 8 |
> kdebase which is depended on by (among others) kdegraphics, without the |
| 9 |
> old kde-3.4.x, kdegraphics-3.4.x would be trimmed by --depclean, and once |
| 10 |
> all the other kdewhatever-3.4.x packages had been trimmed, then |
| 11 |
> kdebase-3.4.x could be trimmed, and then kdelibs-3.4.x |
| 12 |
|
| 13 |
Nope. And it's not going to change anytime soon. A safer --prune, however, |
| 14 |
does have a good chance of going into portage 2.1.3 (to fix bug #151653). |
| 15 |
|
| 16 |
> However, I'm using the split packages, not the monolithics, and don't have |
| 17 |
> kde-meta merged as I don't need all the split packages either. |
| 18 |
|
| 19 |
Doesn't really make a difference. The most basic deps (arts and kdelibs) don't |
| 20 |
differ at all. The problem with using kde as a test case is that kde-3.4 left |
| 21 |
the tree 4 months ago... ;) |
| 22 |
|
| 23 |
-- |
| 24 |
Bo Andresen |
Archives