El Martes, 22 de octubre de 2013, Knoll Lars escribió: > So much for Linux distributions keeping binary compatibility.
Isn't exactly the same situation as with Qt? When the "next version of Qt 4.8" breaks binary compatibility, libqt5 is introduced. You link against either one or the other, and generally, both could be available for you to choose. I'm surprised that libudev0 is not there, though. I suppose all applications that used libudev0 are ported to the new one. > Not > providing the package means you break every 3rd party app that needs > libudev and doesn't come as part of the package management. Which is the point of the package system of all distributions, isn't it? And I might add that is such a good idea that Microsoft and Apple also introduced similar concepts in their (desktop) systems. Let me add a bit of constructive criticism: I've been a fan of the installer framework and the Qt SDK. I understand that is not going away for a variety of reasons, and that in some use cases is the best approach to having a binary installer of Qt, Creator, etc. But after using it a lot, I've found the several issues: - Recommended it to coworkers, and they installed it under the suggested directory ($HOME/Qt, if I recall correctly). Is the preferred place anyway since you don't have permissions to install in the root of the FS. Then another person wants to use the SDK in the same computer as well (but with a different account), so uninstall it, create some world-writable directory, and run the installer, this time pointing it to /opt/Qt. Now the other users are able to see the binaries and run them, but they don't have the shortcuts! Let's copy the files under ~/.config and ~/.local from one user to the other. Done (finally). - After the nice experience of having the latest Qt available for development, I realize is not going to be so easy to put it in the target machine, since it is headless (yes, the app is QtCore/Network only), and I can't run the installer there. I ended copying the files from my PC, but I had to tweak LD_LIBRARY_PATH since the RPATH pointing to the developer's HOME is not very useful. :) After this, my opinion is that the preferred way to go should be to think more in native package system for Linux. For example, Clang is shipping nightly builds through the package system: http://llvm.org/apt/ (ok, this are deb packages only, but the OBS provides several types of binaries for many distributions) I don't know if it should be done downstream, or as additional binaries to what distributions offer. All I can say is that in the next months I'm going to need binaries of Qt 5.2 that work on Debian stable. Since that's not going to be provided by official repositories, I would prefer if the work is not wasted just for my own use case, so I will knock doors to see if somebody else is interested, or I can share the work with Debian packagers. Thank you. -- Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 http://barnacity.net/ | http://disperso.net _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
