Won't this break co-installability with kdelibs4?

In D16520#350807, @apol wrote:

Won't this break co-installability with kdelibs4?

in what way exactly?

note that the kwallet package already did install org.kde.kwalletd.service, but also, kdelibs4 apps should be able to use kwalletd5 via the old interface name

In D16520#350809, @damjang wrote:

in what way exactly?

note that the kwallet package already did install org.kde.kwalletd.service, but also, kdelibs4 apps should be able to use kwalletd5 via the old interface name

So now both kdelibs4 and kf5-kwallet will be installing org.kde.kwalletd.service and the package manager will complain.

So now both kdelibs4 and kf5-kwallet will be installing org.kde.kwalletd.service and the package manager will complain.

that was the case even before my patch

The old kwalletd(4) from kde-runtime newer installed a service file, as far as I can see.

The org.kde.kwalletd.service from kwalletd5 only serves one purpose - start the old kwalletd4 as a source for the migration agent. IMHO the much better approach would be to check for QStandardPaths::findExecutable("kwalletd")and execute it.

The change to the service file is IMHO fine - kwalletd5 implements both versions (which are actually the same interface save the service name), but before doing this change the migration agent has to be changed.

I also wouldn't mind when the migration agent where gone completely - KDE4 is EOL for 3 years, and if there are some persons late to the game they can still export the the old wallets manually and reimport.

but before doing this change the migration agent has to be changed.

Can you expand on this what needs to be changed? I'd be happy to do it if it's in my capability

In D16520#350934, @damjang wrote:

but before doing this change the migration agent has to be changed.

Can you expand on this what needs to be changed? I'd be happy to do it if it's in my capability

There are two possibilities here:

1. Scrap the migration agent completely, only manual wallet migration.
2. Use execute + listen for NameOwnerChanged DBUS event instead of using the current hackish D-BUS activation

Re 1., I would like to get some feedback first - FreeBSD is probably the last supported distribution still shipping KDE4, and only for 2 more months

Pseudo-Code for 2:

kwallet4 = QStandardPaths::findExecutable("kwalletd");
if (kwallet4) {
    QProcess process(kwallet4);
    process.start();
    // wait for DBusConnectionInterface::serviceRegistered("org.kde.kwalletd") signal
}

is it ok if the waiting on the legacy kwallet4 is made synchronous? wiring all those signals will make my head explode :)

wait 5 sec, otherwise give up on the migration?