Summary says it all. All other .upd files in /usr/share/kconf_update/ contain Version=5. So either it's missing of okular still distributes an .upd file from KDE times. The problem occured on neon user and neon dev unstable installations.
Why should it have a version=5?
At least in the log kconf_update claims that it skips the conf file if a verison=5 is not at the right place ( locking at the upd files it looks like Version=5 has to be the first entry): $ journalctl --user | grep -i version=5 Okt 07 17:30:15 lap-allee plasma[10450]: "Missing \"Version=5\", file '/usr/share/kconf_update/krdb_libpathwipe.upd' will be skipped." Okt 07 17:30:15 lap-allee plasma[10450]: "Missing \"Version=5\", file '/usr/share/kconf_update/okular.upd' will be skipped." Okt 13 09:21:13 lap-allee plasma[1596]: "Missing \"Version=5\", file '/usr/share/kconf_update/krdb_libpathwipe.upd' will be skipped." Okt 13 09:21:13 lap-allee plasma[1596]: "Missing \"Version=5\", file '/usr/share/kconf_update/okular.upd' will be skipped." Okt 13 09:23:46 lap-allee plasma[2704]: "Missing \"Version=5\", file '/usr/share/kconf_update/krdb_libpathwipe.upd' will be skipped." Okt 13 09:23:46 lap-allee plasma[2704]: "Missing \"Version=5\", file '/usr/share/kconf_update/okular.upd' will be skipped."
Adding David and Matthew, i wonder why this extra/weird requirement wasn't communicated to app developers, how are we supposed to know that you decided to break the files we ship? Reading the log all i can find is a weird "This patch is necessary because: When we use kf5 + kde4 application" which is a situation we've never supported. Is there any chance you can revert that misfeature?
The original reason this was added was that KDE4 update scripts would get run by KF5, creating a configuration file. Then the KDE4 migration would not run, resulting in users losing their settings. This was put in at the time to stop that from occurring. Ideally, kconf_update would not create an empty configuration file for a migration just to note the migration had been run. However, there are some side effects to that change which make it more complicated to implement, and thus has not yet happened. Without fixing kconf_update, I don't want to back out the change as it still has a good reason. I also like that all the update files now have an enforced version header, which will make it easy to update the format in the future. And most configuration file update scripts should now have the header if required, so there will likely be more pain to revert it at this time. However, you do raise the good point that this requirement is not well communicated. That should definitely be fixed. Is there any particular place you would have expected this information to be present? Also, if the configuration update script is for KDE4 configuration files, you can skip putting a Version=5 header at the top. Instead, you can have the fully updated file migrated to the new configuration file location and start with a fresh update script for KF5. Or continue adding to the file. Whatever works best for okular.
(In reply to Matthew Dawson from comment #4) > The original reason this was added was that KDE4 update scripts would get > run by KF5, creating a configuration file. Then the KDE4 migration would > not run, resulting in users losing their settings. This was put in at the > time to stop that from occurring. > > Ideally, kconf_update would not create an empty configuration file for a > migration just to note the migration had been run. However, there are some > side effects to that change which make it more complicated to implement, and > thus has not yet happened. > > Without fixing kconf_update, I don't want to back out the change as it still > has a good reason. I also like that all the update files now have an > enforced version header, which will make it easy to update the format in the > future. And most configuration file update scripts should now have the > header if required, so there will likely be more pain to revert it at this > time. Ok > > However, you do raise the good point that this requirement is not well > communicated. That should definitely be fixed. Is there any particular > place you would have expected this information to be present? the kde-devel mailing list seems like a good place to me to warn kde developers that a change like this is happening, since otherwise we're not going to see it easily. > > Also, if the configuration update script is for KDE4 configuration files, > you can skip putting a Version=5 header at the top. Instead, you can have > the fully updated file migrated to the new configuration file location and > start with a fresh update script for KF5. Or continue adding to the file. > Whatever works best for okular. For my application there's no such thing as "KDE4" configuration files, they are just configuration files, and ideally one should be able to go from an old version (based on kdelibs4, irrelevant) where the okular.upd had not been run to the new version (based on KF5, irrelevant) and get okular.upd run and then the config be migrated to the new location. As I understand you're saying that this is impossible and thus i basically should just remove the .upd file?
(In reply to Albert Astals Cid from comment #5) > (In reply to Matthew Dawson from comment #4) > > Also, if the configuration update script is for KDE4 configuration files, > > you can skip putting a Version=5 header at the top. Instead, you can have > > the fully updated file migrated to the new configuration file location and > > start with a fresh update script for KF5. Or continue adding to the file. > > Whatever works best for okular. > > For my application there's no such thing as "KDE4" configuration files, they > are just configuration files, and ideally one should be able to go from an > old version (based on kdelibs4, irrelevant) where the okular.upd had not > been run to the new version (based on KF5, irrelevant) and get okular.upd > run and then the config be migrated to the new location. > > As I understand you're saying that this is impossible and thus i basically > should just remove the .upd file? The situation may have changed since this was brought up. At the time, you'd use the Kdelibs4Migration class ( https://api.kde.org/frameworks/kcoreaddons/html/classKdelibs4Migration.html ) to move the file to the new KF5 location (using the XDG directory instead of the .kde directory). The upd file wasn't used for that purpose. If using the upd file is now the recommended way to do the migration, then you can ignore my suggestion. I'm not sure though the upd file is flexible to handle custom kde prefixes that Kdelibs4Migration does.
The new okular.upd (created for the new annotation toolbar) has the Version=5 entry, so this report does no longer apply.