Re: [gentoo-user] Re: FIXED: Re: KDE3 removal

[Alan McKinnon]

On Friday 27 November 2009 17:27:30 James wrote:
> Mick <michaelkintzios <at> gmail.com> writes:
> > Hmm, I thought that kweather, kate and kfloppy were brought in by some
> > meta or other.  It seems that I'll have to install these on their own?
>
> Hello Mick,
>
> I'm just not certain any more exactly which packages belong to
> which meta(kde) package. I think they are added and dropped
> over the last few years, resulting in a dynamic grouping
> or like those you mentioned, not being picked up by and of the
> kde-meta packages.

You fellows really need to read the full set of portage man pages. You sound 
like mechanics that don't know how spanners work.

The contents of packages is determined by upstream (KDE), not by the gentoo 
devs. Gentoo devs merely split the monolithic tarballs up into whatever apps 
the KDE devs say is inside it
 
To find out what is in a -meta package:

cat $PORTDIR/kde-base/*-meta/*ebuild 

There isn't a special tool to do this, much as there isn't a tool to tell you 
what stuff DEPENDs on say apache. There is a general tool, it's 
equery depends -a

> Some time ago kde-meta ( the package that calls other kde-meta(sub
> group packages) was to be done away with.

You are mistaken. 

That has never ever been the case. The monolithic ebuilds have been done away 
with in favour of split ebuilds. This has been in planning for 2 years right 
from the beginning of the KDE-3.5 series

> Now, magically,
> kde-meta is back, after the "Sets" solution seems to be
> too cumbersome for those of us that want a simple and easy
> method to install a bulk of kde packages.

Citation please :-)

Zac has never to my knowledge said that sets are too cumbersome for regular 
people. Sets are not yet in stable portage because he wants the feature to be 
tested more. Therefore sets cannot be exposed in the portage tree. That's why 
defined sets are only distributed in the overlays, not in the tree.


> Other than this '10,000' foot view, you'll have to get more
> precise information from the gentoo kde devs or others,
> as I just do not know......

To find out what depends on kate, kweather and kfloppy, use the correct 
portage tool:

alan@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])

alan@nazgul ~ $ equery depends -a kweather
 * Searching for kweather ...
kde-base/kdetoys-meta-4.3.1 (>=kde-base/kweather-4.3.1:4.3[kdeprefix=])
kde-base/kdetoys-meta-4.3.3 (!kdeprefix ? >=kde-base/kweather-4.3.3[-
kdeprefix])
                            (kdeprefix ? >=kde-
base/kweather-4.3.3:4.3[kdeprefix])

alan@nazgul ~ $ equery depends -a kfloppy
 * Searching for kfloppy ...
kde-base/kdeutils-meta-4.3.1 (floppy ? >=kde-
base/kfloppy-4.3.1:4.3[kdeprefix=])
kde-base/kdeutils-meta-4.3.3 (floppy & !kdeprefix ? >=kde-base/kfloppy-4.3.3[-
kdeprefix])
                             (floppy & kdeprefix ? >=kde-
base/kfloppy-4.3.3:4.3[kdeprefix])


So kate DEPENDS on kdesdk (it's a dev tool, emerge it individually if you just 
want the editor)
kweather DEPENDS on kde-toys
kfloppy DEPENDS on kdeutils iff USE=floppy

> You'd think there'd be a master listing of (kde-4) packages
> and which one belong to which meta-package or what not;
> if not a script to tool to reveal this information....

There is. See above.

> Let me know if you find a silver bullet (syntax) for discerning
> what kde packages are grouped into which meta package or
> not grouped at all..

This is Unix. We use grep, sed and awk to find stuff.

Much faster than just about anything else...

-- 
alan dot mckinnon at gmail dot com