backwards compatibility & how namespacing might help or not

[Harald Sitter]

On Tue, Jan 27, 2015 at 11:54 PM, Albert Astals Cid <aacid at kde.org> wrote:
> 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 kde.org> 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.

Well, they aren't the same file, not really anyway. Even if the
content was exactly the same, gcc for example will slap a build-id
into the binary such that it will not be the same across rebuilds of
the same source IIRC. So establishing the sameness is tricky business.
Contextual newness to decide that version A of a file is newer than B
and thus is better is also slightly tricky, just because one thing is
newer than the other doesn't mean that it actually is a replacement
for the other. A non-framework example for this would be kipi and
kopete both installing different youtube icons into the same path.

So on a binary distribution level the kgobalaccel case certainly
conflicts with a possible no-overwrite policy in the package
management, albeit a reasonable policy I feel given the problem scope.

On a source level it's a problem as well though.
I have Plasma 5.1, I install Frameworks 5.7, it overwrites the
kglobalacceld, I need to rebuild 5.1 because an optional dep was
missing and thus a feature wasn't built I need, it now overwrote the
kglobalacceld again. Assuming the framework expects a given interfaces
to be present on the daemon dbus API the framework will now start to
misbehave because I rebuilt Plasma :'<
This is a bit of a corner case but it definitely isn't like this is a
binary only problem. I for one do happen to sometimes recompile third
party stuff without getting the latest version first ;)

HS