Distros and QtWebEngine

[Matthias Klumpp]

2015-04-20 23:41 GMT+02:00 Thomas Lübking <thomas.luebking at gmail.com>:
> On Montag, 20. April 2015 23:02:34 CEST, Sune Vuorela wrote:
>
>> Let's just try to follow that thru.
>>
>> A new QuigleyImageView pulls in a new Qt. The newer Qt breaks somehow
>> Plasma,
>> because relying on internals. Then a newer Plasma is pulled in. THat ...
>
>
> You can apply that on really *anything* - the obvious (claimed) failure is
> "Qt breaks somehow Plasma" because either
> a) a client relied on undocumented behavior (client bug) or
> b) a foundation broke documented API/ABI/Behavior (foundation bug)
>
> Also your list implies that one never can update KDE, because that breaks
> GNOME, requires a kernel update and whatnot.

(Taking my Debian developer hat)

Yes, stuff like that happens and is absolutely common - that's why we
have a development cycle, where we tune the distribution to have all
parts working well together. If we make a huge update on one part, we
might end up breaking more things than we solve issues.

>> Unfortunately, I haven't really used my imagination here.
>
> That implies the Linux SW stack is crap. Point taken.

Well, it's not crap, but... ;-) Different upstreams care for different
things: Some care very much for backward compatibility and never break
API or ABI. Others, however, break API/ABI with every single release,
remove features and add new ones or even decide to rewrite the whole
application. They might also drop support for lower versions of
dependency X at any time.
I don't say this behaviour is bad, but it makes it impossible to plan
for changes, and to be 100% certain that a change does not break other
unrelated software.
When we release a new version of Debian, users expect the current
feature set to remain stable, so they can tune their workflow to it
and be sure it does not randomly break because a software decided to
e.g. remove command-line flag which became unsupported upstream. The
same way, the quick webbrowser updates are a huge issue in the
enterprise.

In order to keep the whole thing we call a "distribution" sane, we
have a set of rules, like "do not duplicate code in the archive". This
ensures that we do not need to patch the same thing over and over
again, in case there is a security hole in the respective code block.

So, in summary: The free software stack is a mess, and distributors
align it to produce a working compilation of software. This is simply
because there is no central authority coordinating the development of
Mesa, Plasma, GNOME, GCC, systemd, etc., so incompatibilities can
arise at any time.

Cheers,
    Matthias