KDE 4.8.1 doing strange things with some applications

[Duncan]

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 ?
>  >=app-office/akonadi-server-1.5.80)
> 
> 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:

kde-base/kdelibs[semantic-desktop?]

But kdelibs wouldn't care about how dolphin was built.


Instead, the dolphin dependency is (the equivalent of):

kde-base/kdelibs[semantic-desktop=]

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 
USE=semantic-desktop.

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 
uses semantic-desktop.

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 
with it...

-- 
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.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.