On Monday 26 of January 2015 17:22:49 Harald Sitter wrote: > ahoy ahoy > > so... > kf5.7 will contain kglobalacceld5 > plasma5.2 will also contain kglobalacceld5 if it was built with kf5.6 > > this poses a binary conflict which makes kf5.7 not a simple "drop-in" > replacement for kf5.6 without recompiling plasma, which effectively > makes this new construct just like the old construct (kde sc) but with > more repos :'< > > problem: > this presents a compatibility problem as (for example) kubuntu > couldn't drop kf5.7 into an update of a released system without also > rebuilding plasma-workspace. > add on top of that the fact that plasma-workspace might do any > arbitrary amount of things when built against kf5.7 (disable features, > add features, explode, whatever) and it effectively disqualifies any > frameworks release after 5.6 being landed in a manner where one can > somewhat tightly control regression impact (at least to the > understanding of ubuntu on how to make the scope as small as > possible). > this is not the advertised compatibility :P > > solution: > everything ever should be namespaced somehow. kglobalacceld5 should > have a kf5 suffix or prefix, headers should go into a kf5 directory, > cmake packages should have kf5 somewhere in their name etc. etc. > > while discussing this on IRC the issue was raised that the artifacts > installed by a framework couldn't possibly be kept 100% conflict free > with the outside world. while that is of course true I propose that > rigorous namespacing on our side kicks the ball to whoever conflicts > with us and in general renders the likelihood rather small altogether. > > there are of course various additional considerations to be made and > in particular when moving bits from plasma or even applications into > frameworks a proper backwards compatible transition path ought to be > worked out for each case specifically. so even with namespacing the > grey cells need some exercise for sure. > > > at the end of the day I suppose the question we need to answer is do > we want to strive for 100% compatibility or is a best-effort > compatibility good enough. > > best-effort sure is cheaper, it does however also mean that I doubt at > least kubuntu will ever put frameworks releases into the regular > updates procedure, preventing a good chunk of users from getting these > releases. this is in of itself not a bad thing, but it does mean that > a third party developer who wishes to target for example Ubuntu will > have to jump through hoops to get the latest and greatest frameworks > to the user. > > thoughts? (not direct solution for the 'principle' of question, but at least in this case, we've had kglobalaccel5 daemon in a separate subpackage of the plasma- workspace source on openSUSE, precisely as it was hinted already some time ago the merge might happen. we did the same with drkonqi.)
Cheers, Hrvoje > HS > _______________________________________________ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
