On martes, 22 de noviembre de 2016 01:06:00 ART André Pönitz wrote: > On Mon, Nov 21, 2016 at 03:49:49PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > > On domingo, 20 de noviembre de 2016 12:53:11 ART André Pönitz wrote: > > [snip] > > > > > - people using Qt in applications distributed by packaging > > > > > > systems (read "Linux distributions"). They are not affected > > > by BC breakages. > > > > Users might not notice if we maintainers have to deal with this nightmare. > > That's what I said. > > 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. > > > 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
Because it's not just a few applications nor a few archs nor a day or two of rebuilding stuff nor Qt alone. Let's take for example the work we Debian maintainers need to do on every minor Qt update due to private symbols. As you all should know Qt ships private headers which should only be used by Qt itself. But there are people out there that need to use those private headers in order to be able to, for example, provide a native theme. Of course Qt will not bump SONAME and that's fine by definition, because they are private headers. But we maintainers need to deal with it somehow. One way to achieve it will mean rebuilding the whole set of apps using Qt, but that's definitely too much. Using something we call "symbols files" we where able to first hack a way to determine which apps uses private symbols (and then thanks to Thiago providing us with tagged symbols we improved it quite a lot). So we get down to something like this: <http://perezmeyer.com.ar/ben/> Of course that only shows 2 out of the 11 archs we have. It will seem a pretty easy list, most of it being Qt submodules. That alone on the best case scenario takes us 3 to 5 days. Last time we did it it got tangled with an openssl transition as both of them needed to rebuild the same package: calibre. It took us more than a week to solve the issue, but hey, it's what packagers do :-) (sadly not for a living ;-) ) Now if you break BC at, let's say, libqt5core5 we would need to rename it to something like libqt5core5abi1 and rebuild the whole stack of stuff using Qt. The list of the example above would probably crawl to level 7 with quite some more packages on each level. A transition like that would definitely take like a month, in which no other transition will probably be able to happen because Qt is *so* widely used. > while running a full test cycle (Qt > doesn't guarantee behavioural compatibility between versions, any > versions for that matter) is not. > > I fear that the answer is something along the lines of "we > might run a smoke test, but no more", isn't it? No. > > 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? As I described above: by stopping half a distribution to be updated by too much time. > 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. We know and do understand this. But the side effects that it ships are not negligible too. We would suffer a lot from them. -- Un viejo proverbio de El.Machi dice que la memoria es como las papas fritas... ¡nunca sobran! Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
