Re: KDE 4.8.1 doing strange things with some applications
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
dE . posted on Fri, 23 Mar 2012 21:25:23 +0530 as excerpted:
> On 03/23/12 21:02, Kevin Krammer wrote:
>> On Friday, 2012-03-23, dE . wrote:
>>> On 03/21/12 03:56, Duncan wrote:
>>>> One big difference, however, would be that I've disabled
>>>> semantic-desktop entirely, and don't have kdepim
>>>> or akonadi or any of that stuff on the system.
>>> So all this Akonadi stuff comes via [semantic-desktop]?
>> Unlikely, the technoligies themselves are unrelated and Gentoo usually
>> doesn't add artifical dependenices (AFAIK).
>> Some KDEPIM applications are users of both though, so they might look
>> related. But I would be surprised if they were on their package level.
> Humm... thanks for the pointers, this's what I found -
> equery depends app-office/akonadi-server
> * These packages depend on app-office/akonadi-server:
> kde-base/kdepim-common-libs-4.7.4 (>=app-office/akonadi-server-1.3.60)
> kde-base/kdepim-runtime-4.7.4 (>=app-office/akonadi-server-1.3.60)
> kde-base/kdepimlibs-4.7.4-r1 (semantic-desktop ?
> query depends kde-base/kdepim-common-libs
> * These packages depend on kde-base/kdepim-common-libs:
> kde-base/knotes-4.7.4 (>=kde-base/kdepim-common-libs-4.7.4:4[aqua=])
The key point re gentoo/kde with semantic-desktop is that they have "="
depends (as opposed to "?" depends) for anything with semantic-desktop.
Which meant that if you wanted one thing with semantic-desktop, it had to
be turned on for the entire kit-n-kaboodle.
Now, it makes sense that if you want semantic-desktop support for say,
dolphin, that kdelibs must be built with it as well. But the reverse,
that if you have kdelibs built with semantic-desktop, dolphin must be
built with it as well, does-not-follow. Dolphin depends on kdelibs and
kdelibs needs semantic-desktop support for dolphin to have it, but kdelibs
does not depend on dolphin, nor should dolphin be forced to semantic-
desktop support just because kdelibs has it.
That would be modeled by "?" deps. Again using the dolphin example,
dolphin should have this dependency:
But kdelibs wouldn't care about how dolphin was built.
Instead, the dolphin dependency is (the equivalent of):
That forces dolphin to be built with semantic-desktop if kdelibs is,
which doesn't make sense.
Complicating things further, using akonadi effectively forces semantic-
desktop on for kdelibs. The actual dependency is a bit convoluted and
there's several package dependency layers in between, but the final
effect is that akonadi ultimately requires that kdelibs be built with
And as I said above, due to all those forced = deps that really SHOULD be
? deps, that forces ALL installed kde packages that have the semantic-
desktop USE flag to enable it as well.
And since anything kdepim related pulls in kdepim-common-libs as a
dependency, and kdepim-common-libs pulls in akonadi-server, that means
that the moment you install anything kdepim related, even if it doesn't
itself (yet) require akonadi, it pullsin kdepim-common-libs, which DOES
require akonadi-server, which in turn forces kdelibs to USE=semantic-
desktop, which in turn forces it for everything ELSE kde related that
Thus, at least as the gentoo/kde deps are currently configured, the
moment you install anything kdepim related, it forces semantic-desktop
for EVERYTHING kde related.
The key to turning off semantic-desktop for ANYTHING, then, is to
uninstall anything that's part of kdepim, so that kdepim-common-libs can
be uninstalled, so that akonadi-server can be uninstalled, so that kdelibs
no longer has to be compiled with USE=semantic-desktop to support akonadi,
which now allows semantic-desktop to be toggled -- as a single option for
everything else due to those = deps -- for the rest of kde.
But if any part of kdepim is installed, it forces kdepim-common-libs
which forces akonadi-server which forces semantic-desktop ON kdelibs,
which forces it on for ALL of kde due to the = deps. Thus, the ONLY way
to get rid of USE=semantic-desktop is to kill anything kdepim related
thus allowing akonadi-server to be uninstalled.
So why the cursed = deps?
That is a bit of a long story, and in fact if you read the monthly gentoo/
kde meeting announcements as posted on the gentoo-desktop list, you'll
see that they're actively debating changing it back to ? deps, thus
solving a huge part of the problem (tho akonadi-server would still
indirectly force USE=semantic-desktop for kdelibs, and anything kdepim
based would indirectly pull in akonadi-server via kdepim-common-libs, but
at least the rest of kde could be built without semantic-desktop, while
keeping people's kdepim apps of choice).
But the short form of the story is that apparently, back in the early
kde4 era when all these components and their dependencies were still
evolving, gentoo/kde DID have semantic-desktop? deps, and it caused
strange bug reports both at gentoo and filed by gentoo users with kde
itself. Again, back then, all these components and their
interdependencies were still rapidly evolving at the time, as was gentoo/
kde's understanding of them, and rather than have to fight with
continually adjusting dependencies and weird gentoo-user-only bug reports
both at gentoo and upstream kde, they decided to force those = deps that
are causing users who'd otherwise have semantic-desktop off for most of
kde, so many problems today.
The good news is that as I said, gentoo/kde is actively considering
revising those forced = deps to the less strict ? deps, and will very
likely do just that at some point. But there's a lot of testing to be
done first, especially since the forced = deps allowed fuzzier dep-specs
in other cases, that will now trigger bugs if the = is switched to the
less strict ?, and all those fuzzy/missing dependencies need to be found
and fixed in gentoo/kde's packages, certainly before they reach stable,
and preferably while they're still hard-masked in the gentoo/kde overlay,
before they're unmasked to ~arch in the overlay, let alone hit the main
tree for ~arch users there.
I'd guess they'll be testing it in the overlay during 4.8, with the
results hopefully hitting the stable tree by late 4.8 or more likely, not
until 4.9 stabilizes. Of course, that assumes they decide to go ahead
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
More info: http://www.kde.org/faq.html.
[Red Hat Install]
[GIMP for Windows]
[Red Hat Development]