On Thu, Jan 9, 2014 at 10:50 AM, Loïc Minier <loic.min...@canonical.com> wrote: >> Qt 5.2 is now at ppa:canonical-qt5-edgers/qt5-beta2 [1] - updates to >> Qt will come, but for example most synchronizations of packaging with >> Debian have been done already. > > This is not ok; we can't break the apps already in the app store; we > have to preserve binary compatibility.
Yes, for my part this effort is about bringing Qt 5.2 to trusty and making everything compatible with it, not about which way to handle compatibility in app store. But as mentioned also in the quoted post, I've mentioned the app store compatibility need to anyone asking about Qt 5.2 landing requirements, and nudged people to find someone to work on what's needed for app store. > This probably means we have to introduce a qt 5.0 source package > providing the old package names. I'm not sure, but if that way would be selected it may mean we need to patch and rename not only all Qt 5.2 release and snapshot modules (binary + source), but also all QML modules and other such packages for co-installability. Qt 5.x itself is around 20 packages, plus then >80 packages that depend on Qt, of which some percentage are QML modules and such that the apps may depend on. These renames would also mean differentiating all packages from Debian. > Did the SONAME change adequately for this transition? This is needed to > allow both libraries to be installed at the same time and the runtimer > linker to find the right one. The current approach of not bumping soname was agreed with Debian at http://bugs.debian.org/731261 where Steve L. asked for a libqt5core5 -> libqt5core5a package rename to help us. This approach works nicely so that we're now in sync with both Debian and upstream and I'm progressing on getting fixes one package at a time so that we hopefully would have Qt 5.2 based images soon, as there are not many weeks until feature freeze. For the app store and compatibility story, as discussed on IRC, different people apparently have different ideas on how it should be done - co-installing, not breaking binary compatibility at all, ABI support packages / chroots - I'm sure I don't undestand the whole of it. But since I've my mind full enough of the current Qt 5.2 trusty work (+ landing integration), my humble wish is that whatever way would be so that it can be done transparently enough so that the already risky Qt 5.2 transition isn't made more risky or delayed by the other changes. -Timo -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp