Bug 422291
| Summary: | qt4 config script tries to execute from wrong places | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> |
| Component: | qt4 | Assignee: | Than Ngo <than> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 8 | CC: | kevin, laurent.rineau__fedora, rdieter |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 4.4.0 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-11-26 10:45:16 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
> This is obviously broken
qt4's packaging uses rpm's notion of %{_libdir} to define QT(4)DIR, so I fail to
see how this is broken (obviously or otherwise). How is querying rpm for
%_libdir any worse than querying rpm for %arch (and making assumptions what
libdir is/should-be based on what %arch is)?
> Actually on x86_64 I may have installed i386 qt4 packages
I think I get it now. Hrm... an odd use case, having qt4.i386 without the
primary arch (qt4.x86_64) being installed, I'm not sure how we could reasonably
accomodate that.
setarch i386 /usr/bin/qtconfig-qt4
should do the right thing (as long as rpm behaves and /etc/rpm/platform doesn't
get in the way).
I'll keep pondering, maybe we can/should get rid of all this hackery, and just
put all of qt4's bin's into %{_bindir} (instead of %_libdir/qt4/bin), and let
rpm do it's own multilib thing.
> qt4's packaging uses rpm's notion of %{_libdir} That precisely what is broken. There is not the slightest guarantee that this is what is used for a particular installed instance of qt4. > Hrm... an odd use case, having qt4.i386 without the > primary arch (qt4.x86_64) being installed What so odd about it? There is no requirement for qt4.x86_64 to be present if nothing is using it. Just to make /usr/bin/qtconfig-qt4 happy? That seems excessive. :-) > I'm not sure how we could reasonably accomodate that. Both variants of an alternate code for /usr/bin/qtconfig-qt4 shell script handle the situation without any hiccups. It is easy to give a preference for 64-bit QT4DIR if 64 and 32-bit library variants happen to be present. You aren't supposed to install packages of the compat arch without the primary arch version on a multilib system, if you do that you're on your own. In any case, this kind of problems is why I made sure KDE 4's libexecdir is
actually under /usr/libexec, not %{_libdir}. But for qt, we're a bit stuck,
because RPM doesn't support replacing a directory with a symlink (see bug
446167), the existing packages install %{_libdir}/qt4/bin as a directory and
some apps expect the Qt 4 executables to be under %{_libdir}/qt4/bin. So I'm
not sure how to fix this properly. :-( What we could do is keep it as a
directory and symlink the individual executables, similarly to how we symlink
them the other way round right now.
> You aren't supposed to install packages of the compat arch without > the primary arch version on a multilib system ... Say again? Why not? Clearly nothing is wrong with that if only a compat arch is used. > RPM doesn't support replacing a directory with a symlink You surely do not want a symlink here as on other occasions packages for multiple architectures could be installed and you would create conflicts. In any case I do not understand what is wrong with a trivial search for qtconfig as outlined in the original report. If installing "primary arch" makes possible to configure "secondary arch" of qt4 then obviously you do not care which qtconfig binary you are running as long as you found one. AFAICS such run should only rewrite /etc/Trolltech.conf so this indeed works. Otherwise you are screwed in a multilib situation no matter what. The symlink was a link _from_ %{_libdir}/qt4/bin _to_ %{_bindir}, so there are
no conflicts, the RPM glitch (directory->symlink conversions not supported) is
the problem.
> In any case I do not understand what is wrong with a trivial search
nothing wrong, a valid short-term hack, but not a good long-term strategy to
properly support multilib.
> ... not a good long-term strategy to properly support multilib.
I am missing what are long-term bad effects of such approach but I assume
that you have something real in mind.
So what about recording a value of QT4DIR in a package installation time
via package scripts? Say in its own section of /etc/Trolltech.conf, if
that is possbile, or in /etc/sysconfig/qt4? The later likely simpler.
A package "knows" its own architecture, so this is not an issue, and
we clearly want only _a_ valid value for QT4DIR so we do not care what
"wins" as long as some really existing location is there. One needs
to be careful when only some architectures are deinstalled.
That way also other programs from ${QT4DIR}/bin could be made available.
> /etc/Trolltech.conf, if that is possbile, or in /etc/sysconfig/qt4?
Nope, more multilib conflicts. We have some better ideas in mind, rest assured. :)
Our long-term plan is to put the actual executables in _bindir and symlinks or wrapper scripts in _qt4_bindir, not the other way round, that way multilib conflicts (and script hacks etc.) immediately become a complete non-issue. > Our long-term plan is to put the actual executables in _bindir ...
Is this not running into that snag that /usr/lib/qt4/bin/qtconfig
and /usr/lib64/qt4/bin/qtconfig are two different files and similar
for all other "ELF xy-bit LSB executable" there?
Apparently I am missing something here but whatever ...
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping This has been already fixed with our qt4-4.4.0 packages. |
Description of problem: /usr/bin/qtconfig-qt4 contains the following code if [ -z "$QT4DIR" ] ; then # rpm is more correct multilib-wise, provided /etc/rpm/platform doesn't get in the way. QT4DIR="$(/bin/rpm --eval "%{_libdir}/qt4" 2>/dev/null || /usr/bin/pkg-config --variable=prefix QtCore )" export QT4DIR fi This is obviously broken (not mentioning that "/usr/bin/pkg-config" does not really have a chance to execute) because assumes that an architecture of a machine, as reflected by %{_libdir}, implies an architecture of installed packages. Actually on x86_64 I may have installed i386 qt4 packages (in order to use, say, skype). In such situation "Qt4 Config" shows up on "Preferences" menu but it is doing, not so surprisingly, silently nothing. The following replacement code seems like the simplest way to do the job: if [ -z "$QT4DIR" ] ; then if [ -x /usr/lib/qt4/bin/qtconfig ] ; then QT4DIR=/usr/lib/qt4 elif [ -x /usr/lib64/qt4/bin/qtconfig ] ; then QT4DIR=/usr/lib64/qt4 else exit 1 fi export QT4DIR fi If you still want to querry through rpm this is still possible but is getting more involved. For example, something like this: if [ -z "$QT4DIR" ] ; then if arch=$(/bin/rpm -qf --qf '%{arch}\n' \ /usr/bin/qtconfig-qt4 2>/dev/null ); then arch=$(echo "$arch" | head -n 1) case "$arch" in x86_64|ia64|s390) QT4DIR=/usr/lib64/qt4 ;; *) QT4DIR=/usr/lib/qt4 ;; esac export QT4DIR else exit 1 fi fi It needs to take into account that qt4 got installed for multiple architectures. Version-Release number of selected component (if applicable): qt4-4.3.2-4.fc8 How reproducible: always