On Saturday 28 November 2009 21:32:28 Mick wrote:
> > 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
>
> Sorry I'm being rather dense with this ... are you saying that the DEPENDs
> listed when you run 'equery depends -a kate' are different to mine because
> you are running KDE4 from KDE-testing overlay, while I am running stable
> portage?
>
No, the contents of the -meta packages are pretty much the same between the
overlay and the official tree (apart from new apps added in the latest KDE
snapshots, and other minor things that get dropped in the new branch of
course).
The kde-testing overlay provides a collection of sets which the portage tree
does not do. The main set explicitly includes kate because it's part of kdesdk
and it's a bit rich to expect all users to install the entire dev suite just
to get a gui text editor.
The official tree has the same situation:
# grep kate /var/portage/kde-base/*-meta*/*4.3.3.ebuild
/var/portage/kde-base/kde-meta/kde-meta-4.3.3.ebuild: $(add_kdebase_dep
kate)
/var/portage/kde-base/kdesdk-meta/kdesdk-meta-4.3.3.ebuild:
$(add_kdebase_dep kate)
# cat /var/portage/kde-base/kde-meta/kde-meta-4.3.3.ebuild
...
RDEPEND="
$(add_kdebase_dep kate)
$(add_kdebase_dep kdeadmin-meta)
...
To give kate to users, it was added to kde-meta, and it's the only explicit
DEPEND in the ebuild, everything else is the smaller -meta packages.
To get kate, you must do one of:
1. emerge kde-meta (or the @kde set)
2. emerge kdesdk (or the @kdesdk set)
3. emerge kate
--
alan dot mckinnon at gmail dot com
