Bug 422291 - qt4 config script tries to execute from wrong places
qt4 config script tries to execute from wrong places
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: qt4 (Show other bugs)
8
All Linux
low Severity medium
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-12 14:04 EST by Michal Jaegermann
Modified: 2008-11-26 05:45 EST (History)
3 users (show)

See Also:
Fixed In Version: 4.4.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-26 05:45:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2007-12-12 14:04:31 EST
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
Comment 1 Rex Dieter 2007-12-12 14:47:44 EST
> 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)?
Comment 2 Rex Dieter 2007-12-12 14:53:30 EST
> 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.
Comment 3 Michal Jaegermann 2007-12-12 15:10:34 EST
> 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.
Comment 4 Kevin Kofler 2008-05-13 03:30:46 EDT
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.
Comment 5 Kevin Kofler 2008-05-13 03:48:59 EDT
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.
Comment 6 Michal Jaegermann 2008-05-13 11:44:33 EDT
> 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.
Comment 7 Kevin Kofler 2008-05-13 11:49:59 EDT
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.
Comment 8 Rex Dieter 2008-05-13 11:54:30 EDT
> 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.
Comment 9 Michal Jaegermann 2008-05-13 12:44:28 EDT
> ... 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.
Comment 10 Rex Dieter 2008-05-13 12:51:21 EDT
> /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. :)
Comment 11 Kevin Kofler 2008-05-13 13:21:09 EDT
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.
Comment 12 Michal Jaegermann 2008-05-13 13:34:59 EDT
> 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 ...
Comment 13 Bug Zapper 2008-11-26 03:58:29 EST
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
Comment 14 Kevin Kofler 2008-11-26 05:45:16 EST
This has been already fixed with our qt4-4.4.0 packages.

Note You need to log in before you can comment on or make changes to this bug.