emerge -p k3b These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild N ] kde-base/kdebase-l10n-3.4.0_beta1 [ebuild N ] kde-base/khelpcenter-3.4.0_beta1 [ebuild N ] kde-base/kpager-3.4.0_beta1 [ebuild N ] kde-base/kdepasswd-3.4.0_beta1 [ebuild N ] kde-base/kdcop-3.4.0_beta1 [ebuild N ] kde-base/klipper-3.4.0_beta1 [ebuild N ] kde-base/kfind-3.4.0_beta1 [ebuild N ] kde-base/ksysguard-3.4.0_beta1 [ebuild N ] kde-base/kstart-3.4.0_beta1 [ebuild N ] kde-base/ksystraycmd-3.4.0_beta1 [ebuild N ] kde-base/ktip-3.4.0_beta1 [ebuild N ] kde-base/drkonqi-3.4.0_beta1 [ebuild N ] kde-base/kxkb-3.4.0_beta1 [ebuild N ] kde-base/knetattach-3.4.0_beta1 [ebuild N ] kde-base/kscreensaver-3.4.0_beta1 [ebuild N ] kde-base/nsplugins-3.4.0_beta1 [ebuild N ] kde-base/khotkeys-3.4.0_beta1 [ebuild N ] kde-base/kappfinder-3.4.0_beta1 [ebuild N ] kde-base/kdebase-pics-3.4.0_beta1 [ebuild N ] kde-base/kdebugdialog-3.4.0_beta1 [ebuild N ] kde-base/kdialog-3.4.0_beta1 [ebuild N ] kde-base/kdebase-meta-3.4.0_beta1 [ebuild U ] app-cdr/k3b-0.11.18-r1 [0.11.18] Is this right? Or are there far too many dependencies listed? If you can choose to install KDE without i18n and the helpcenter, why can't you do the same for k3b ? TIA! Reproducible: Always Steps to Reproduce: 1. 2. 3.
I built this k3b --nodeps, and basically everything seems to work as expected (no i18n of course, no help pages etc.), but it is just as functional as the rest of kde without i18n or helpcenter. Maybe, new kde-USE flags are needed to really take advantage of the split kde ebuilds? I read this (http://dev.gentoo.org/~danarmak/kde-split-ebuilds.html): Split and monolithic ebuild interoperability Split and monolithic ebuilds can be mixed freely. The only restriction is that a monolithic ebuild can't be installed at the same time as a split ebuild deriving from it. There are blocking deps in the ebuilds that enforce this, so you can do anything emerge allows you to do. However, I know of no no reason to actually do this. You should just use the split ebuilds for all your needs. The split ebuilds are also the default ebuilds. This means that when some other ebuild depends on a KDE application, it will want to install a split ebuild. However, the matching monolithic ebuild will also satisfy that dep, so you can emerge the monolithic ebuild manually and then emerge the ebuild that depended on it. [/quote] Does this mean kdebase-meta should not be a dependency for k3b, "a lot less" ?
This is normal as you look at the ebuild. We have to track down what's/are the kde-base parts really needed by k3b and other kde programs so, for now we have putted the fulle kdebase-meta. For k3b I think that the needed ones are kcontrol and kcminit as RDEPEN but I'm not completely sure. If you can make more tests and report them we'll be happy. thanks.
I did an emerge k3b, without the KDE-dependency in the ebuild on a system without any KDE-components present. Needed for a succesful emerge: only kdelibs. For a functional k3bsetup, one needs to emerge kdesu For burning (i just tested the erasing and burning of a data cd) you need nothing else. Note: you have no systray integration, no helpfiles, no i18n, the rest appears functional. (wow, I just realised: these few lines of text took almost one day of emerging on my nimble testing-machine)
Thanks AlterEgo to find this out. I hope to update the ebuild in the next days.
I committed 0.11.19, changing the dependency to 'kdesu'. Please everyone test it and report if there's something wrong.
I use to edit the k3b ebuild and make k3b to depend on kdebase-startkde and not on kdebase-meta. The dependencies are not so extreme and k3b works with no problem.
