Upgrade note for kscreenlocker to Plasma 5.10

[Martin Gräßlin]

Am 2017-03-09 17:07, schrieb 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.

oh misunderstanding. I talked about the transition to 5.10. For future 
transitions it can be different. But I still would like to have this 
handled in the upgrade step. We have had problems with upgrading:
* Interaction ksld -> kscreenlocker_greet
* Interaction kscreenlocker_greet and lnf package
* Interaction kscreenlocker_greet and kcheckpass

In many cases this results in very ugly checks in the code which I don't 
like as it's security critical code. (e.g. your suggestion for a 
protversion command line check is a no-no given the code in question) 
And we never know when we can remove the checks. Is an upgrade path 5.8 
-> 5.10 without 5.9 in between legit? How long do we need to support it?

We are doing ourself a big disservice by trying to support a runtime 
situation with parts of version x and x+1. This is a situation which is 
hardly tested and we have seen it fail soooo often in the past (I could 
give you a long list of bug reports).

Given that I would love to see all distros switching their upgrades of 
Plasma version to being offline. Kscreenlocker is in my opinion only the 
tip of the iceberg. It's the one thing where we see it fail because we 
get the complaints if the system cannot be unlocked any more. For any 
other part it's quite unknown how it behaves. Is a KWin of version x 
compatible with an Alt+Tab theme of x+1? Can Plasma handle the exchange 
of all Qml components? Given that my personal recommendation is to do 
offline updates.

Cheers
Martin