backwards compatibility & how namespacing might help or not

Albert Astals Cid aacid at
Tue Jan 27 22:54:11 UTC 2015

El Dimarts, 27 de gener de 2015, a les 10:28:24, Harald Sitter va escriure:
> On Mon, Jan 26, 2015 at 10:01 PM, Albert Astals Cid <aacid at> wrote:
> > Yeah, i don't think that what you suggest really helps much, otherwise
> > you'd end up with two kglobalaccels running at the same time, which is
> > probably a very bad thing.
> It's dbus invoked, so in the kglobaccel case specifically david
> edmundson suggested that correct naming of the service file in
> frameworks would make sure that it is the file used by dbus-daemon to
> run the service.
> A potentially more interesting problem would be KIO slaves moving
> about, as I don't think there is any provisioning for two slaves
> providing the same protocol and having one outrank the other.
> > So yes, a better way of moving thing arounds is needed, or maybe we just
> > need the dust to settle a bit so that we realize where each thing really
> > belongs and it'll hopefully fix itself?
> Waiting for the dust to settle is what I have been told for almost a
> year now. How much more dust can there possibly be? :P
> The problem IMO is that supposedly the existing things will settle at
> some point, that doesn't mean a new thing couldn't end up in some
> plasma repo for 5.7 and then be moved into a framework 5.130 because
> it suddenly fits better into frameworks.
> As a community we should at the very least decide whether or not
> frameworks ought to be runtime compatible with non-frameworks bits
> (such as plasma) and follow through with that.
> If we don't want to have this level of compatibility then it's fine as
> well, it just needs to be made clear I feel.
> As of right now I don't think anyone ever told me that runtime bits
> aren't supposed to be compatible when I highlighted a conflict because
> of things moving about. It always was a lot of handwaving and
> explaining that things are still changing. And to be quite honest, if
> things are changing such that I can not upgrade my frameworks without
> having to recompile or upgrade something unrelated as well, that feels
> a lot like a BIC.

Totally, upgrading your frameworks should not need you to recompile or upgrade 
unrelated nor related stuff.

Note that in this case (kglobalaccel) you don't need to do nothing, it just 
overwrites whatever was there on plasma, so it is more a packaging issue 
(packaging doesn't like two packages to write the same file to the same place 
even if it's the same file) than a recompiling/upgrading thing.


> HS
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at

More information about the Kde-frameworks-devel mailing list