André Pönitz wrote: > I also said that packagers (i.e. people like you) *are* affected, but I > claimed the way they are affected is not fundamentally different from > what happens if the packages in question uses any other library that > doesn't guarantee BC, or - in case they have similar BC promises like Qt > - what happens when there are jumps in major versions.
The problem is that Qt is a very widely used library, and that it is also used by many libraries used by other libraries used by other libraries, all of which also use Qt directly (e.g. KF5-*). The "all of which also use Qt directly" part is how this differs from something like libpng which is usually only used through higher-level APIs. Most applications do not link directly to libpng. (In fact, we do this: http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtbase.git/tree/qt5-qtbase.spec#n562 to avoid Qt applications needlessly linking directly to libpng etc. We cannot do this with Qt because its APIs are used both directly and transitively.) >> If Qt exposes a non-Qt lib trough it's API then whenever that non-Qt >> lib break ABI we need to get Qt rebuilt and *everything* building >> against it. > > I understand that. > > What I do not understand is how rebuilding an application can be > considered a significant burden while running a full test cycle (Qt > doesn't guarantee behavioural compatibility between versions, any > versions for that matter) is not. It is not *an* application. It is *many* libraries and applications. > I fear that the answer is something along the lines of "we > might run a smoke test, but no more", isn't it? Well yes, testing is what our users do daily. What we need to take care of is to not have broken dependencies (or worse, symbol lookup failures at runtime because the ABI was changed without a soname bump). Otherwise, the application will not run at all. >> That's the worth nightmare we distro maintainers can dream >> on. And yes, we would need to adjust Qt's SONAME on each change. > > That's maybe one per year. With a typical distro running, say, two > bigger updates per year replacing most packages anyway, that would > ill-affect a distro user... how? In Fedora, the issues this would cause are twofold: 1. In Rawhide, we would have to rebuild all packages using Qt, which are dozens, each time such a thing happens. But, due to the transitive dependency issue I mentioned at the beginning, they would have to be rebuilt in reverse dependency order. So we would first have to compute that. Our tools do not do it for us. The mass rebuilds Fedora release engineering does for some releases are always done in alphabetical order. That will not work if so many libraries have broken dependencies. 2. In Fedora, Qt is often updated to a newer version in a release, as an official update. And even when not, the newer version is typically offered in a Copr repository (a Fedora "PPA"). That would not be reasonably doable anymore if the new version were not binary-compatible. As in Debian's case, the packages (ab)using private APIs are already enough of an issue for us as it stands. But at least we have a list of those, and their interdependencies are limited, whereas rebuilding ALL packages using Qt would be orders of magnitude larger and not suitable for an update nor (realistically) even a Copr at all. Major versions of Qt (i.e., 3, 4, 5, …) are the right place to change the ABI, because there, we just make both versions coexist, and the transition becomes relatively smooth. But also breaking binary compatibility in the minor releases would not really scale. > I am not here trying to make your life harder. I do understand that you > would be on the receiving end in case Qt BC guarantees are lowered. I > believe I understand the effort packagers invest, and the benefit this > has for the Qt ecosystem. But the BC guarantee comes at quite some > price like the inability to fix certain mistakes that slipped into some > x.0 release, or to use certain features that only became usable a some > x.5 time, and this price is payed both by developers and end users. But if our users were to be stuck at, say, Qt 5.8 because 5.9 would be binary-incompatible, they would be losing much more features. > This is not a zero-sum game, there's room for total improvement, and > since BC is not the only thing packagers care for a loss of BC could > possibly get compensated by something dev can influence. At the very > least I see no reason to forbid thinking about it. You can always think about it, but if you do so, you will quickly find that it is not practical at all. Marco Bubke wrote: > I strongly agree with Andre'. And is a BC break in the time of flat pack > that bad? As an user I really looking forward to flat pack, so I can > update my heavily used Applications and being not dependent on > distribution. This package could be much better optimize with LTO and > profile guided optimization. Maybe sharing everything is not that smart > anymore. How does Flatpak solve the issue? Qt is not a leaf package. You cannot offer a Qt Flatpak, none of the applications using Qt would get the improvements from such a Qt. You would have to Flatpak each and every application. We want to offer newer Qt releases as a distro-wide drop-in update for all applications to benefit. Kevin Kofler _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
