Kevin, any suggestions/clues why this dependency isn't satisified by kde-workspace's
kwin/scripting/scripting.cpp
code already?

I believe this is one reason why we added this snippet to kde-workspace.spec awhile back:

# kwin apparently provides this internally, kwin/scripting/scripting.cpp
# our scripts can't grok it automatically
Provides: plasma4(scriptengine-declarativescript)
Provides: plasma-scriptengine-declarativescript = %{version}-%{release}

The problem is that plasmapkg knows neither about the RPM database (i.e. our explicit Provides) nor about the stuff internally provided by KWin. It (in my kdelibs patch 0002) asks Plasma for whether it has the needed script engine, and, if not, triggers the PackageKit prompt.

This is the code I'm using:
+    // check for missing dependencies
+    QString requiredScriptEngine = meta.implementationApi();
+    if (!requiredScriptEngine.isEmpty()) {
+        // figure out the component type to query for
+        ComponentTypes componentTypes = static_cast<ComponentTypes>(0);
+        QStringList serviceTypes = meta.serviceType().split(',');
+        if (serviceTypes.contains("Plasma/Applet")) {
+            componentTypes |= AppletComponent;
+        }
+        if (serviceTypes.contains("Plasma/DataEngine")) {
+            componentTypes |= DataEngineComponent;
+        }
+        if (serviceTypes.contains("Plasma/Runner")) {
+            componentTypes |= RunnerComponent;
+        }
+        if (serviceTypes.contains("Plasma/Wallpaper")) {
+            componentTypes |= WallpaperComponent;
+        }
+        if (!knownLanguages(componentTypes).contains(requiredScriptEngine)) {
+            // install the missing script engine
+            // force prompting because the user has just explicitly installed a widget
+            ComponentInstaller::self()->installMissingComponent("scriptengine", requiredScriptEngine, 0, true);
+        }
+    }
+    QStringList requiredDataEngines = meta.requiredDataEngines();
+    if (!requiredDataEngines.isEmpty()) {
+        QStringList knownDataEngines = DataEngineManager::self()->listAllEngines(meta.application());
+        foreach (const QString &requiredDataEngine, requiredDataEngines) {
+            if (!knownDataEngines.contains(requiredDataEngine)) {
+                // install the missing data engine
+                // force prompting because the user has just explicitly installed a widget
+                ComponentInstaller::self()->installMissingComponent("dataengine", requiredDataEngine, 0, true);
+            }
+        }
+    }

I'll have a look into how to best handle the KWin stuff. (Maybe I should just skip the whole ComponentInstaller code when the service type is not one of the 4 expected ones.)

This should fix it:
http://pkgs.fedoraproject.org/cgit/kdelibs.git/commit/?id=558270b8dcb1f6aabc57394f64b82e48a758227a
(currently only built for Rawhide, and the ARM build is still running there).

Can you please test the following scratch build?
http://koji.fedoraproject.org/koji/taskinfo?taskID=6535919

(That's a kdelibs-4.11.5 build for Fedora 20 with the fix. I did it as a scratch build because the official update will be for 4.12.2, which is now in updates-testing.)

(In reply to Kevin Kofler from comment #4)

Thanks for acting so quicky on this.

> Can you please test the following scratch build?
> http://koji.fedoraproject.org/koji/taskinfo?taskID=6535919

I'd like to but being new to Linux/Fedora/KDE I need some help.
I guess I need to install all rpms from http://koji.fedoraproject.org/koji/taskinfo?taskID=6535935
As there are inter dependencies I figured I would try to pass all rpms to yum: 
--------
[piotr@demon tmp]$ sudo yum install ./kde*
(...)
Transaction Summary
Install  2 Packages (+39 Dependent packages)
Upgrade  3 Packages

Total size: 922 M
--------

I take these 39 Dependent packages to mean it's not the right way...
So I tried to install kdelibs-4.11.5-2.fc20.x86_64.rpm:
--------
[piotr@demon tmp]$ sudo yum install ./kdelibs-4.11.5-2.fc20.x86_64.rpm
Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit
Examining ./kdelibs-4.11.5-2.fc20.x86_64.rpm: 6:kdelibs-4.11.5-2.fc20.x86_64
Marking ./kdelibs-4.11.5-2.fc20.x86_64.rpm as an update to 6:kdelibs-4.11.5-1.fc20.x86_64
Resolving Dependencies
--> Running transaction check
---> Package kdelibs.x86_64 6:4.11.5-1.fc20 will be updated
---> Package kdelibs.x86_64 6:4.11.5-2.fc20 will be an update
--> Processing Dependency: kdelibs-common = 6:4.11.5-2.fc20 for package: 6:kdelibs-4.11.5-2.fc20.x86_64
--> Finished Dependency Resolution
Error: Package: 6:kdelibs-4.11.5-2.fc20.x86_64 (/kdelibs-4.11.5-2.fc20.x86_64)
           Requires: kdelibs-common = 6:4.11.5-2.fc20
           Installed: 6:kdelibs-common-4.11.5-1.fc20.x86_64 (@updates)
               kdelibs-common = 6:4.11.5-1.fc20
           Available: 6:kdelibs-common-4.11.3-9.fc20.x86_64 (fedora)
               kdelibs-common = 6:4.11.3-9.fc20
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest
--------

As it depends on kdelibs-common-4.11.5-2.fc20 I tried to install this first:
--------
[piotr@demon tmp]$ sudo yum install ./kdelibs-common-4.11.5-2.fc20.x86_64.rpm
Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit
Examining ./kdelibs-common-4.11.5-2.fc20.x86_64.rpm: 6:kdelibs-common-4.11.5-2.fc20.x86_64
Marking ./kdelibs-common-4.11.5-2.fc20.x86_64.rpm as an update to 6:kdelibs-common-4.11.5-1.fc20.x86_64
Resolving Dependencies
--> Running transaction check
---> Package kdelibs-common.x86_64 6:4.11.5-1.fc20 will be updated
--> Processing Dependency: kdelibs-common = 6:4.11.5-1.fc20 for package: 6:kdelibs-4.11.5-1.fc20.x86_64
---> Package kdelibs-common.x86_64 6:4.11.5-2.fc20 will be an update
--> Finished Dependency Resolution
Error: Package: 6:kdelibs-4.11.5-1.fc20.x86_64 (@updates)
           Requires: kdelibs-common = 6:4.11.5-1.fc20
           Removing: 6:kdelibs-common-4.11.5-1.fc20.x86_64 (@updates)
               kdelibs-common = 6:4.11.5-1.fc20
           Updated By: 6:kdelibs-common-4.11.5-2.fc20.x86_64 (/kdelibs-common-4.11.5-2.fc20.x86_64)
               kdelibs-common = 6:4.11.5-2.fc20
           Available: 6:kdelibs-common-4.11.3-9.fc20.x86_64 (fedora)
               kdelibs-common = 6:4.11.3-9.fc20
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest
--------
And here I'm lost...

Btw, could you elaborate on the reason for this error which you briefly described in comment 2 so that someone like me without knowledge of KDE and Fedora could understand?

You need to update kdelibs and kdelibs-common together, as they depend on each other. (The unwanted additional dependencies when you tried with kde* probably come from kdelibs-devel. The -devel, -apidocs and -debuginfo packages are all optional, and you apparently don't have them installed, so you don't have to update them either.)

So in short, you want:
sudo yum install ./kdelibs-4.11.5-2.fc20.x86_64.rpm ./kdelibs-common-4.11.5-2.fc20.x86_64.rpm
(all in one line).

So, does that fix your problem?


And to answer your question, the problem in my code I quoted in comment #2 is that it asks Plasma for what script engines it has available for applets (widgets) if you are installing a Plasma applet (widget), data engines if you are installing a Plasma data engine, runners if you are installing a Plasma runner or wallpapers if you are installing a Plasma wallpaper (the ones animated by scripts). Now the problem is that what you are installing is none of these, but a KWin script. That is not a Plasma component to begin with, but only reuses the "Plasma package" infrastructure. Therefore, Plasma cannot know what script engines are available for KWin scripts. (There is, in fact, exactly one, declarativescript, hardcoded in KWin itself.)

Therefore, I fixed the code so that if what you are installing is not one of the 4 known Plasma component types listed above, it will just not ask Plasma for whether the script engine is available, and instead assume it is available. At least for KWin scripts, the "declarativescript" script engine (the only allowed one) is provided by KWin itself and therefore always available. If the script engine is really missing at runtime (when KWin tries to load it), you get a PackageKit prompt for it at runtime, but in KWin, that should never happen.

(Sorry, given that you are installing KWin scripts from git, I was somehow expecting you to be familiar with KWin development, or I would have written something more detailed right away.)

(In reply to Kevin Kofler from comment #6)
> You need to update kdelibs and kdelibs-common together, as they depend on
> each other. 

That kdelibs package depends on kdelibs-common I can see looking at 'Requires: kdelibs-common = 6:4.11.5-2.fc20' line. But how would I know that kdelibs-common depends on kdelibs if all I see is 'Requires: kdelibs-common = 6:4.11.5-1.fc20' when trying to install/up kdelibs-common?

> (The unwanted additional dependencies when you tried with kde*
> probably come from kdelibs-devel. The -devel, -apidocs and -debuginfo
> packages are all optional, and you apparently don't have them installed, so
> you don't have to update them either.)
> 
> So in short, you want:
> sudo yum install ./kdelibs-4.11.5-2.fc20.x86_64.rpm
> ./kdelibs-common-4.11.5-2.fc20.x86_64.rpm
> (all in one line).

Thanks for info.
 
> So, does that fix your problem?

Yes, it does. After installing with
sudo yum install ./kdelibs-4.11.5-2.fc20.x86_64.rpm ./kdelibs-common-4.11.5-2.fc20.x86_64.rpm
the problem is gone:
[piotr@demon kwin-tiling]$ plasmapkg --type kwinscript -i .
Successfully installed /var/tmp/kwin-tiling

> And to answer your question, the problem in my code I quoted in comment #2
> is that it asks Plasma for what script engines it has available for applets
> (widgets) if you are installing a Plasma applet (widget), data engines if
> you are installing a Plasma data engine, runners if you are installing a
> Plasma runner or wallpapers if you are installing a Plasma wallpaper (the
> ones animated by scripts).

What's the reason for probing for these? Is it to avoid installing something already installed or is it to make sure some dependencies are met?

> Now the problem is that what you are installing
> is none of these, but a KWin script. That is not a Plasma component to begin
> with, but only reuses the "Plasma package" infrastructure. Therefore, Plasma
> cannot know what script engines are available for KWin scripts. (There is,
> in fact, exactly one, declarativescript, hard-coded in KWin itself.)

It sounds like "promoting" scripts to component status would allow for clean integration with existing infrastructure which apparently is designed around component model.

> Therefore, I fixed the code so that if what you are installing is not one of
> the 4 known Plasma component types listed above, it will just not ask Plasma
> for whether the script engine is available, and instead assume it is
> available. At least for KWin scripts, the "declarativescript" script engine
> (the only allowed one) is provided by KWin itself and therefore always
> available. If the script engine is really missing at runtime (when KWin
> tries to load it), you get a PackageKit prompt for it at runtime, but in
> KWin, that should never happen.
 
I take "At least for KWin scripts(...)" to mean there are other types of scripts. If so then could it be that changing behavior to "not ask Plasma for whether the script engine is available" could lead to them not functioning in part or in whole?

Also after I read your statement from comment #2:

> The problem is that plasmapkg knows neither about the RPM database (i.e. our
> explicit Provides) nor about the stuff internally provided by KWin. It (in

it seems like plasmapkg is neither integrated with the distribution ("knows neither about the RPM database") nor with KDE/Plasma itself ("nor about the stuff internally provided by KWin"). If that's the case then it's rather glaring shortcoming of plasmapkg if not the whole packaging model.  Are there any plans to fix this?

> (Sorry, given that you are installing KWin scripts from git, I was somehow
> expecting you to be familiar with KWin development, or I would have written
> something more detailed right away.)

Sure. Thank you for taking time to answer all my questions. I'm aware my questions are rather general and are not directly relevant to this issue. If you could point me to some docs where I could read more about packaging in KDE/Plasma that would be nice.


The last question – would you agree with faho's statement (https://github.com/faho/kwin-tiling/issues/14#issuecomment-35181315) that "It's a Fedora bug"?

Not strictly a fedora-only
 bug.  It's a bug in a feature we helped develop for upstream, to dynamically install plasma resources on demand via PackageKit.  Fedora happens to be one distro that enables this feature by default.  Some don't.

> That kdelibs package depends on kdelibs-common I can see looking at 'Requires:
> kdelibs-common = 6:4.11.5-2.fc20' line. But how would I know that
> kdelibs-common depends on kdelibs if all I see is 'Requires: kdelibs-common =
> 6:4.11.5-1.fc20' when trying to install/up kdelibs-common?

Well, strictly speaking, kdelibs-common does not depend on kdelibs, but kdelibs depends on the exact version of kdelibs-common ('=' versioned dependency, not '>='), so you cannot upgrade one (no matter which one) without also upgrading the other.

> > So, does that fix your problem?
>
> Yes, it does.

Great. I'm going to push official updates.

> It sounds like "promoting" scripts to component status would allow for clean
> integration with existing infrastructure which apparently is designed around
> component model.

That's why they use the Plasma package infrastructure in the first place. My point is that the script is not a PLASMA component, but a KWin component, so libplasma doesn't know what script engines are available to it. (Only KWin knows.)

> I take "At least for KWin scripts(...)" to mean there are other types of
> scripts.

Actually, I don't know whether there are any other components other than the 4 types of Plasma components I listed and KWin scripts using the Plasma package infrastructure. "At least for KWin scripts" means that I cannot speak about anything else because I don't know if it even exists, let alone how it works if it does.

> If so then could it be that changing behavior to "not ask Plasma for whether
> the script engine is available" could lead to them not functioning in part or
> in whole?

It will definitely work no worse than in upstream because the feature to prompt for script engine installation with PackageKit exists only in Fedora. (Upstream only carries the first part of my 3-part patchset, which snuck in accidentally after the kdelibs 4 permanent feature freeze, and it is now disabled by default upstream (because they refused to merge the other 2 patches and I refused to maintain the incomplete feature in that state). The feature which causes the problem here is part of the patch 2 (of 3), which is not upstream at all.)

> it seems like plasmapkg is neither integrated with the distribution ("knows
> neither about the RPM database") nor with KDE/Plasma itself ("nor about the
> stuff internally provided by KWin").

Plasmapkg is integrated with Plasma. KWin is not part of Plasma. (We are talking about the software actually called Plasma here, not about the marketing term "Plasma Workspace" which includes the whole KDE workspace including KWin. Blame upstream for their ambiguous terminology.)

@Rex Dieter:
> Not strictly a fedora-only bug.

This is definitely a Fedora-only bug. Patch 0002 is not upstream and will never be (because kdelibs 4 is feature-frozen). In fact, patch 0001 only entered by accident in the first place (which is one of the reasons it's now disabled by default upstream).

> It's a bug in a feature we helped develop for upstream, to dynamically install
> plasma resources on demand via PackageKit.  Fedora happens to be one distro
> that enables this feature by default.  Some don't.

AFAIK, Fedora happens to be THE one distro that enables this feature by default, unfortunately. :-(

kdelibs-4.12.2-3.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/kdelibs-4.12.2-3.fc20

kdelibs-4.11.5-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/kdelibs-4.11.5-2.fc19

After some updates have been installed (currently KDE is 4.12.2) I see this error again. How to make sure I have KDE with the patch applied (kdelibs-4.12.2-3.fc20)?

It will hit updates-testing in the next push, if you want it now, get it from:
http://koji.fedoraproject.org/koji/buildinfo?buildID=498598
and install it the same way you had installed 4.11.5-2.fc20.

Package kdelibs-4.12.2-3.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kdelibs-4.12.2-3.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-2715/kdelibs-4.12.2-3.fc20
then log in and leave karma (feedback).

So, effective now, you should be able to install the fixed version with:
sudo yum --enablerepo=updates-testing --advisory=FEDORA-2014-2715 update

(Don't ask me why Bodhi still fails to tell you that instead of the line it gives you, which doesn't always work when subpackages are involved. That said, in this case, the line suggested by Bodhi should also work.)

kdelibs-4.12.2-3.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Created attachment 866381 [details]
update notification with special message icon next to kdelibs entry

Why do I see this special message icon next to kdelibs entry in update notification?

That's the icon of one of the .desktop files in kdelibs. PackageKit/Apper tries to be helpful and show icons from .desktop files, which makes sense for application packages, not so much for libraries of course.

Ok, but why do I see this icon next to kdelibs and no other entry? Also it's the first time I see this icon although I've seen several update notifications in the past. Coincidentally the information is about fixing this very bug which I raised...

Because the other packages do not have any .desktop files in them.

kdelibs-4.11.5-2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.