Hello, Kdelibs ebuilds was modified this week in order to make it depend on kdebase-runtime-meta. Kdebase-runtime-meta pulls in a lot of other dependencies, which are not required for KDE! Would it be possible to revert this change or at least give the users the choice between kdebase-runtime-meta and the previous dependencies (kdebase-data ktimezoned)? Regards, Thank you in advance Reproducible: Always
+1 for reverting.
These are the packages that would be merged, in order: Calculating dependencies... done! !!! All ebuilds that could satisfy ">=sys-apps/hal-0.5.9" have been masked. !!! One of the following masked packages is required to complete your request: - sys-apps/hal-0.5.14 (masked by: package.mask) /etc/portage/package.mask: # Don't want these, ever - sys-apps/hal-0.5.13-r2 (masked by: package.mask) - sys-apps/hal-0.5.12_rc1-r8 (masked by: package.mask) - sys-apps/hal-0.5.12_rc1-r7 (masked by: package.mask) - sys-apps/hal-0.5.12_rc1-r6 (masked by: package.mask) - sys-apps/hal-0.5.11-r9 (masked by: package.mask) (dependency required by "kde-base/solid-4.3.4" [ebuild]) (dependency required by "kde-base/solidautoeject-4.3.4" [ebuild]) (dependency required by "kde-base/kdebase-runtime-meta-4.3.4-r1" [ebuild]) (dependency required by "kde-base/kdelibs-4.3.4" [ebuild]) (dependency required by "kde-base/kdebase-data-4.3.4" [ebuild]) For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook.
(In reply to comment #2) Sorry for that. I lost my comment in the cut&paste process. What I meant to say was: +1 I suppose this change is resposible to why portage now want hal. I have (until now) managed to avoid hal :)
This also affects the official portage tree and kdebase-startkde. Since kde-4.3.4 kdelibs and kdebase-startkde want to pull in kdebase-runtime-meta, which include ebuilds I don't need and I don't want.
it looks like the origin of this change was due to bug 294025. However, I also think this is excessive. KDE already works perfectly fine for me, but this change is also forcing in: kde-base/kfile-4.3.4 kde-base/kiconfinder-4.3.4 kde-base/kuiserver-4.3.4 kde-base/drkonqi-4.3.4 kde-base/kquitapp-4.3.4 kde-base/kdebase-menu-4.3.4 kde-base/renamedlg-plugins-4.3.4 kde-base/ktraderclient-4.3.4 kde-base/knewstuff-4.3.4 kde-base/knetattach-4.3.4 kde-base/kdebugdialog-4.3.4 kde-base/kwalletd-4.3.4 kde-base/kstart-4.3.4 kde-base/solid-hardware-4.3.4 kde-base/svgpart-4.3.4 kde-base/solidautoeject-4.3.4 none of which I need, and some of which I specifically do not want (drkonqi, knewstuff, knetattach, kwalletd, etc.). I also vote for removing this dependency, as it's overkill. Instead, the specific required packages should be identified and made required. Eg., the ktimezoned is required for timezones to show up in the Clock applet (which was fixed in 4.3.1). Any remaining, specifically required dependencies like that should be identified and listed as dependencies, but not EVERY kde-runtime package. Besides, as was even noted in comments in the previous bug, Gentoo is (fortunately!) all about modularization and customization, and this change isn't exactly aligned with that philosophy.
FYI, this is also a problem with the kdebase-startkde package
*** Bug 295410 has been marked as a duplicate of this bug. ***
*** Bug 295954 has been marked as a duplicate of this bug. ***
*** Bug 295994 has been marked as a duplicate of this bug. ***
As suggested in bug 294025 you can add those packages to package.provided. Altho I do agree this is a workaround that should not be needed.
(In reply to comment #10) > As suggested in bug 294025 you can add those packages to package.provided. > Altho I do agree this is a workaround that should not be needed. > I don't like that workaround one bit. It indicates that I have provided those package in other ways, not that I don't need them.
Another workaround (actually, what I did) is to copy the ebuild (and relevant files/* items) into private portage overlay and delete that line. It is closer to reality.
*** Bug 294025 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > Another workaround (actually, what I did) is to copy the ebuild (and relevant > files/* items) into private portage overlay and delete that line. It is closer > to reality. You need to be careful doing this. It seems that a lot of explicit packages dependencies were removed when the meta package dep was added. As a result, a lot of the components that really are needed are no longer pulled in by default. So, new installs will be messed up, and anyone running a --depclean after the upgrade will also result in a screwed up KDE desktop (speaking from experience...).
In such case, if you open a bug 'App X needs app Y but it's not installed' we will come to your house and kill you, fine with this? :) Upstream (KDE) specifically says kdebase-runtime should be installed for *any* KDE4 application. Any other way is unsupported.
You do not seem to understand that KDELibs has interfaces that work with many of those applications, especially kwalletd and drkonqi. The reversion of this SHOULD NOT OCCUR, as it is causing issues for KDE on the user support mailing lists and forums, with Gentoo users complaining about problems that do not occur on anyone else's systems which is caused because they are missing components which KDE assumes will be present at runtime. These problems are often very difficult to troubleshoot. HAL isn't actually required, the Fake Hardware Backend should be used in that case, but be aware of the consequences this brings for Hardware detection ( ie. no use of external media in Amarok, Device Notifier never shows anything, Dolphin & File Manager dialogs will not detect external storage ) @Jared: " KDE already works perfectly fine for me" - Something won't be working properly... somewhere. Especially since you don't have kwalletd.
I agree that KDE as a whole probably will not work. But as I stated in one of these duplicates -- I use okular and gwenview. I can not imagine either of them using kwalletd, plasma-runtime (I do not use plasmoids with xmonad, really), kinfocenter or desktop theme. First, I think the dependency is on wrong package. Would make more sense to be on kdebase-meta or so. Second, some people, like me, would rather have a "unsupported-do-not-depend-on-everything" use flag with a huge, red, warning "If you do this, you are on your own".
(In reply to comment #16) > @Jared: " KDE already works perfectly fine for me" - Something won't be working > properly... somewhere. Especially since you don't have kwalletd. If something is not working properly, then it's in a component or app that I don't use, and as a result I don't care and don't really want it on my system to begin with. Since you cited kwallet, if some KDE component cannot store my passwords, then that's fine because I don't *want* any KDE components to store my passwords. If I did, then I'd already have kwallet installed and wouldn't have brought that up as an example. Look, I'm not trying to be an ass. I understand your desire, from a KDE perspective, to help ensure users have a solid KDE experience. Believe me, I'm all for it - I've been happily using KDE as my preferred desktop environment since the 1.x days, and I've been encouraging others to try it ever since. But, as has been mentioned in both this bug and your original bug report, Gentoo is about choice. With KDE, I choose *not* to have every package installed, as I don't use every package (and that includes some of the runtime components). Forcing the -meta packages on us now is like taking a giant step backwards to the pre-split ebuild days when that was our *only* choice. To be clear, no one here is not advocating delivering a broken KDE experience. What I'm suggesting is that the necessary dependencies be identified and properly implemented rather than forcing over a dozen new, potentially unnecessary packages upon us. A lot of work had already been done to accomplish this, such as (for a simple example) requiring ktimezoned to provide timezone information for the clock applet - this wasn't found and fixed until 4.3, but it *was* fixed. I feel we should continuing tweaking and refining the packages to deliver a solid AND configurable user experience, just as Gentoo has always done in the past. I'd also appreciate it if you would not make assumptions about how I maintain my computer and what may or may not be broken. I've been running Gentoo+KDE since 2002, and I know quite well what works for me.
If you are using KDE Workspace, then you should have all of runtime installed. ie. it must never be optional. As that is especially where the most of the problems come up. The problem in comment #2 isn't related to this, but to kdelibs. @Jared: Some applications simply *depend* on it. Amarok has problems with Last.fm for instance without KWallet. ktraderclient & kdebugdialog are not absolutely required though. Possibly the same for kfile and solid-hardware. DrKonqi is definitely required, and same with kuiserver. No idea for solidautoeject, kdebase-menu and kiconfinder. They may be optional ( especially the last one ). renamedlg-plugins, knetattach and knewstuff are needed, as they provide features. Don't even know where svgpart comes from. kquitapp is used heavily when supporting users, as it safely shuts down KDE applications, to allow tasks to be performed requiring that they are closed. It must be installed.
If amarok needs kwallet for last.fm support, then you can do it with sth like lastfm? ( media-libs/liblastfm kde-base/kwalletd ) The thing is, when upstream says that kdebase-runtime is applications required by kde, then we have to understand that they are releasing big tarballs of multiple applications and libraries. They also presume you will be installing all of them. In that context it is correct to say that for example kdemultimedia depends on kdebase-runtime. In the gentoo world this corresponds to the time before split ebuilds. One idea behind splitting the big packages is to be able install only stuff that you actually need. That means split ebuilds need more refined dependency checks. You can no longer pull in a myriad of packages just in case something depends on them. So there is a policy decision here: if gentoo wants to maintain split ebuilds for kde, the ebuilds have to reflect a knowlege of what actually depends on what in kde, and that on a program/library/feature basis, not on a tarball basis. For sanitys sake, i hope at least upstream has this knowledge of dependencies. In that case it should be easily reflected in ebuilds. If they don't, they are running into big trouble. Why is windows such a bloat? Because they have no idea what is actually needed in there, so they have to keep everything they ever wrote in just in case.
The main reason why the whole of KDEBase-Runtime should be installed is that the next version of X KDE application could shift its runtime requirements without anyone noticing and suddenly a subtle issue appears in an application ( such as the clock issue... and that was likely around since KDE 4.0 and took until 4.3 to be fixed... )
Who does the job - decides. We (Gentoo KDE team) do the job - we decide. And we decided to follow the way all other distribution take - to pull kdebase-runtime-meta for every KDE4 application as we are unable to track all dependencies per application level. KDE SC contains approx. 250 packages using split Gentoo policy - good luck with "refining dependency checks" for them. Patches welcome!
All very bad excuses... False depend is a false depend. If i'd maintain app-foo/bar and I knew it needs only kdelibs and kdesu, I'd define them in the ebuild. I consider it a major violation of QA when a random library is pulling in several random deps. Dependencies ain't over-complex.
What about pestering upstream about this?
(In reply to comment #22) > Who does the job - decides. > > We (Gentoo KDE team) do the job - we decide. And we decided to follow the way > all other distribution take - to pull kdebase-runtime-meta for every KDE4 > application as we are unable to track all dependencies per application level. Then why bother with split ebuilds at all? One ebuild for every tarball from KDE upstream and everything is fine. Anybody who wants to use a KDE-application (k3b, kile, konversation etc.) has to install the whole KDE-Desktop. We can put the whole KDE-stuff into one ebuild. No more dependency problems anymore...
What I don't understand is why kdebase-runtime is split up and kdelibs isn't. Wouldn't it be easier to split-out what you don't want to build, instead of splitting-out everything then picking up all the pieces? One package is less than 40-something, even if they install the exact same thing. Plus, I bet there's a much higher overhead of handling this on a per package basis. It seems like the install would be quicker if it were all in one go. And, if I have to install most of kdebase-runtime anyways, I'd rather just have one package.
Fixing dependencies on per-package level is a hard way, but the right way. That's the way Gentoo lives: install only what is needed.
I guess we'll have to talk about this bug in our next meeting - 17 December?
(In reply to comment #22) > we are unable to track all dependencies per application level. You mean unwilling...
@Comment 29: The dependencies of an application can change at *any* time between releases. There is no possible way to track this individually.
Which decision was taken following the KDE meeting on December 17th?
(In reply to comment #31) > Which decision was taken following the KDE meeting on December 17th? > It was decided to remove the depend by one vote IIRC
+ 10 Jan 2010; Samuli Suominen <ssuominen@gentoo.org> kdelibs-4.3.4.ebuild: + Remove kde-base/kdebase-runtime-meta from PDEPEND wrt #295456. PDEPEND is now same as in 4.3.3. Sorry it took so long.
@Samuli: Is there any planned effort by those who voted to remove this depend in terms of ensuring that every single component of runtime will be present for applications that need them? Otherwise this is a severe step backwards, and will once again mean that Gentoo users will be much harder to assist & support as the state of what is installed cannot be relied upon.
It was 5:4 vote in favor of removal. So it is their decision now what to do (i already stated i wont bother with those bugs). I already added eclass code that ewarn user if they dont have the package installed. For most people i just simply recommend installing kdebase-startkde or kdebase-meta if they want to rely on their kde features.
@Tomas: Thanks for adding the warning.
(In reply to comment #36) > @Tomas: Thanks for adding the warning. > Also i should note that it is still in overlay, because our inclusion approach for eclasses is bonded with kde bump. So all changes we do in that period of time are included at once :]
(In reply to comment #34) > @Samuli: Is there any planned effort by those who voted to remove this depend > in terms of ensuring that every single component of runtime will be present for > applications that need them? It's bug by bug basis, most of them are INVALID if they only bring in extra functionality as we don't support anykind of Ubuntu style 'Recommends: ' installation, nor we shouldn't. Install at least kdebase-startkde, or deal with it.
We do plan to fix missing depends as we find them or they're reported, but as Samuli said we might close as invalid bugs about optional run-time deps. We're going to add some information in the docs about this and we'll ask all Gentoo users to first check with us and or to install kdebase-runtime-meta before bugging KDE upstream.
