On Saturday 28 November 2009 02:01:22 Mick wrote: > > To find out what depends on kate, kweather and kfloppy, use the correct > > portage tool: > > > > a...@nazgul ~ $ equery depends -a kate > > * Searching for kate ... > > kde-base/kdesdk-meta-4.3.1 (>=kde-base/kate-4.3.1:4.3[kdeprefix=]) > > kde-base/kdesdk-meta-4.3.3 (!kdeprefix ? > > >=kde-base/kate-4.3.3[-kdeprefix]) (kdeprefix ? > > >=kde-base/kate-4.3.3:4.3[kdeprefix]) > > OK, but I am getting this much - slightly different to yours above: > > # equery depends -a kate > [ Searching for packages depending on kate... ] > kde-base/kde-meta-4.3.1 (>=kde-base/kate-4.3.1:4.3[kdeprefix=]) > kde-base/kdesdk-meta-4.3.1 (>=kde-base/kate-4.3.1:4.3[kdeprefix=]) > > Now, fair enough, I do not have kde-base/kde-meta installed, so nothing > wants to pull back in kate when I update world. >
That's normal. The pre-defined sets in kde-testing overlay explicitly list kate in the @kde set for that reason. I suppose one could make several useful -meta packages DEPEND on kate, as many users want kate and do not want the entire kdesdk package. But that causes the same app to appear in more than one -meta package and the devs seem to want to avoid that - there is a strict one-to-one mapping between what the -meta packages install and what is shipped in the upstream tarballs by KDE -- alan dot mckinnon at gmail dot com
