Upgrade note for kscreenlocker to Plasma 5.10

[Fabian Vogt]

Hi,

Am Donnerstag, 9. März 2017, 16:49:09 CET schrieb Martin Gräßlin:
> Am 2017-03-09 08:56, schrieb Fabian Vogt:
> > Hi,
> > 
> > Am Donnerstag, 9. März 2017, 07:10:30 CET schrieb Martin Gräßlin:
> >> Am 2017-03-08 20:12, schrieb Fabian Vogt:
> >> > Hi!
> >> >
> >> > Am Mittwoch, 8. M?rz 2017, 19:50:40 CET schrieb Martin Gr??lin:
> >> >> Hi distributions,
> >> >>
> >> >> I'm currently planning to change the interaction between
> >> >> kscreenlocker_greet and kcheckpass. As a result a kscreenlocker_greet
> >> >> started in Plasma 5.9 won't be able to unlock with a kcheckpass from
> >> >> Plasma 5.10. This is a situation which could happen during an upgrade.
> >> >> Kcheckpass gets invoked when trying to unlock, so an upgrade while the
> >> >> session is locked could result in this situation.
> >> >
> >> > Thanks for letting us know!
> >> > Isn't there a way to make kscreenlocker from the next 5.9 release
> >> > capable
> >> > of unlocking the 5.10 kcheckpass? That way nothing special would
> >> > happen.
> >> 
> >> Even if it were technically possible (which it isn't) it would not 
> >> solve
> >> the
> >> problem as we also want to support transitions like 5.8 (or earlier) 
> >> to
> >> 5.10 (or later)
> > 
> > Wouldn't it be technically feasible for kscreenlocker_greet to just 
> > restart
> > itself if it notices that it cannot talk to kcheckpass anymore?
> 
> No, the old kscreenlocker_greet doesn't know anything about it. Thus it 
> cannot.

Why does it need to? kscreenlocker_greet could just invoke kcheckpass --protocolver
and compare (if it fails, too old). Or cmake writes the version id into a file
in /usr/share and kscreenlocker compares that, or...
KScreenlocker has all the information it needs available as far as I can tell.

Obviously it needs to be handled on the distro side at least once for 5.x -> 5.10.
After that we know that a 5.10 -> X update is always safe.

Otherwise we'd need to kill/offline upgrade with *every* update, which is triggered
by git commits or even changes in dependencies...

Cheers,
Fabian

> Trust me, if there were a solution which would not involve asking 
> distros to
> adjust, I would have implemented it. I spend quite some time thinking 
> about the
> problem and whether we can avoid it.
> 
> I'm sorry it is just not possible.
> 
> Cheers
> Martin