Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 402591 - Feature request: Please make x11-libs/qt-* slotted even on minor version
Summary: Feature request: Please make x11-libs/qt-* slotted even on minor version
Status: RESOLVED CANTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: Qt Bug Alias
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-07 19:44 UTC by Evan Teran
Modified: 2012-02-23 15:05 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Evan Teran 2012-02-07 19:44:34 UTC
Recently I decided to install Qt-4.8 on my box and was unfortunately greeted with many blockers which needed manual resolution. Many of which were based on the fact that the 4.7 versions of the qt packages were installed. In the end I was able to resolve this and things seem to working nicely. But it occurred to me. Why can't the qt ebuilds be slotted to avoid this entirely.

Obviously, you don't want a slot for every single version since most of the time Qt minor revisions are not only source compatible, but are binary compatible. But things like version 4.7 vs. 4.8, Why can't they coexist?

So, I imagine that it could be tackled similarly to how boost is installed:

instead of installed headers to /usr/include/qt4, they could be installed to /usr/include/qt4.7 and have /usr/include/qt4 be a symlink to /usr/include/qt4.7.

Same situation with /usr/share/qt4.

With /usr/lib/qt4, the libraries are already versioned and symlinked to the latest, so that's pretty much done.

Additionally, obviously the tools like /usr/bin/qmake and /usr/bin/moc would need to be managed through symlinks as well.

Finally, we could use something like "eselect qt" to choose which version of Qt we are going to be build against.

Personally, as a developer it would be nice to have multiple versions of Qt installed which I could switch between and test things.

Thoughts?

Reproducible: Always
Comment 1 Markos Chandras (RETIRED) gentoo-dev 2012-02-07 20:27:33 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
Comment 2 Evan Teran 2012-02-09 22:59:38 UTC
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
Comment 3 Davide Pesavento gentoo-dev 2012-02-09 23:15:49 UTC
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?
Comment 4 Markos Chandras (RETIRED) gentoo-dev 2012-02-09 23:19:44 UTC
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
Comment 5 Davide Pesavento gentoo-dev 2012-02-23 15:05:17 UTC
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.