Handling framework packages in distros

[Martin Graesslin]

On Saturday, July 9, 2016 6:42:57 PM CEST Martin Steigerwald wrote:
> Hello!
> 
> In Debian we saw versioned dependencies in KDE framework packages
> repeatedly. Like krunner not working with a partial mix of 5.23 and 5.22
> framework packages in Debian testing¹.
> 
> Thus I want to clarify on upstream recommendations here:
> 
> I bet you do not document and in some cases maybe don´t even know all cases
> where a newer framework module requires another new framework module, but
> rather expect distros to upgrade all KDE Framework packages in lockstep.
> 
> Is that true?

Kind of. Frameworks are considered as one product and a mix of framework 
versions is neither tested nor supported by upstream. Higher tier frameworks 
do specify the dependencies to lower tier frameworks by the same version 
number. That is every dependency is found by the exact version number.

On the other hand updating a framework should not break existing software. I 
don't know what exactly went wrong in the mentioned bug as there is no (?) 
crash trace included and also don't really understand the bug report (too much 
noise). Maybe it's just a missing dependency somewhere?

> 
> Since the order in which packages enter Debian Unstable and especially
> Testing is not predictable this creates issues for users of these Debian
> versions and also leads to bug reports that are interim breakages.
> 
> Any recommendations, any ideas?

A role out of all packages by tiers should work. E.g. first shipping all tier 1 
packages. That should not break any existing package (ABI compatibility and 
things like that) and should be possible to do without an all or nothing. 
Afterwards you could role out tier 2 packages - those should also be possible 
to upgrade without an all or nothing.

For tier 3 I'm not sure. If all dependencies are properly specified a role out 
should also be safe. If you don't know whether all dependencies are set 
correctly I would go for all as one. It's obvious that things break if a 
framework depends on new (runtime) functionality of another framework and 
that's not updated yet. But in the end that's just a missing dependency. If 
you see cases where dependencies are not properly specified upstream, please 
report to us.

As a general note: I would recommend offline updates in distributions. Updates 
can do weird things to running application by e.g. loading newer plugins into 
applications started against the library of the older version. Such situations 
can easily happen with the highly plugin based applications in the KDE world.

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/distributions/attachments/20160711/d98ce1c4/attachment.sig>