Summary: | Feature request: Please make x11-libs/qt-* slotted even on minor version | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Evan Teran <evan.teran> |
Component: | [OLD] Unspecified | Assignee: | Qt Bug Alias <qt> |
Status: | RESOLVED CANTFIX | ||
Severity: | enhancement | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Evan Teran
2012-02-07 19:44:34 UTC
There is no way ( and frankly no reason ) for Qt to be slotted in minor version. It is impossible to select which Qt version you want to use on runtime. The only way to do that is to write an eselect module to re-create the symlinks in /usr/lin64/qt4. Moreover, the headers need to be placed to separate /usr/include/qt4 directories meaning every application out there needs a custom Gentoo patch to compile. So, sorry but we won't do that. I see no reason, even as a developer to test your application against multiple versions of Qt. Your application should always support the latest Qt version. And as far as I know, Qt tries to be backwards compatible. I am closing this as CANTFIX. If anyone is interested in creating a patch then feel free to do so and reopen the bug It is not my intention to be argumentative and certainly it's your call in the end. So If after this you still feel the same way, that's ok, i'll let it go :-). When you talk about patching ebuilds, I am guessing you are referring to situations like this: - both 4.7 and 4.8 are installed - 4.8 is selected by eselect - some ebuild wants to build against 4.7 meaning that the ebuild would have to be patched to build against /usr/include/qt4.7 and /usr/lib/qt4.7. That is certainly a concern i hadn't considered, and may a bit difficult to tackle easily. I don't think the ebuilds for all applications would necessarily have to be patched. qmake generates Makefiles which include things like: INCPATH = -I/usr/include/qt4 ... which comes from qmake itself: $ qmake -query QT_INSTALL_PREFIX:/usr QT_INSTALL_DATA:/usr/share/qt4 QT_INSTALL_DOCS:/usr/share/doc/qt-4.8.0 QT_INSTALL_HEADERS:/usr/include/qt4 QT_INSTALL_LIBS:/usr/lib64/qt4 QT_INSTALL_BINS:/usr/bin QT_INSTALL_PLUGINS:/usr/lib64/qt4/plugins QT_INSTALL_IMPORTS:/usr/lib64/qt4/imports QT_INSTALL_TRANSLATIONS:/usr/share/qt4/translations QT_INSTALL_CONFIGURATION:/etc/qt4 QT_INSTALL_EXAMPLES:/usr/share/qt4/examples QT_INSTALL_DEMOS:/usr/share/qt4/demos QMAKE_MKSPECS:/usr/share/qt4/mkspecs QMAKE_VERSION:2.01a QT_VERSION:4.8.0 If we patching that itself and have /user/bin/qmake actually be a script which runs qmake-4.7 or qmake-4.8, etc depending on an environment variable would cover all ebuilds which use qmake. Personally, I'd favor the environment variable over a symlink so that it can be set in a not system wide manor making it easy to toggle it for ebuilds. This would have very little overhead if the mkspecs files are patched to run things like /usr/bin/moc-4.7 directly. ebuilds which use cmake may or may not need a similar patch. A cursory analysis of /usr/share/cmake/Modules/FindQt4.cmake implies it gets the paths from qmake... So that may be two birds with one stone. Not 100% sure. For manually made Makefiles, yea, they may need patching, but I'm not sure how frequently that occurs. So in the end, I feel that it is a "doable" goal... whether or not it's worth it, is up to you guys, I'll still like Gentoo either way :-). As for the secondary comment, While Qt tries to be backwards compatible, certainly new features are added in new versions. Sometimes, the ideal solution is the have a fallback implementation when compiling against an older version of Qt, so it's nice to be able to test those readily. Thanks for your time And what about dependencies in ebuilds? Currently most ebuilds have dependencies of the form: x11-libs/qt-core:4 or >=x11-libs/qt-core-4.6:4 How would you express such deps if qt was slotted for each minor version? Let's divide users into two main categories - Desktop (aka everyday) users Do thy want multiple Qt versions installed? Why would I want 4.7 and 4.8? When will I need to switch to 4.8 and vice versa? I believe most ( if not every ) desktop users want the latest available package. If this does not work for them, they can simply mask it and keep the old one. If it works for them, then who cares about the previous version :) - Developers Like I said, from my point of view as a part-time Qt dev, I want to test my application against the latest Qt available because this is the one most users will have within the next few weeks in their systems. I am very confident that Qt is backward compatible meaning that an application that used to work in Qt-4.6, will work in 4.7 and 4.8. We've seen some regressions but the majority of packages work just fine. I understand the corner case, like the one you described. What happens to my app if a user has an old Qt version with an unsupported feature? I have to say that you need to play with the odds. Eventually, that user will update to Qt-4.8 at some point. Or you can start developing your application in Qt-4.7 and then switch to Qt-4.8. It is a bit of a pain but it is doable. Or you can remove the current Qt version and emerge a previous one. Excluding qt-webkit, you should be able to build the rest of Qt modules in less than an hour on a fairly recent box. And finally, if you keep binary packages (FEATURES="buildpkg") you can remove and emerge Qt within 10 minutes. In any case, if someone wants to try it, I am not going to stop him but I don't this this implementation reaching portage because it seems too much for the majority of users. I might be wrong though. Reopening in case someone wants to work on that Closing again. There's really no easy way to implement slotting on each minor version, and the motivations to support it are rather weak, as Markos said. |