[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#363150: marked as done (qmake should not be an alternative)



Your message dated Sun, 17 Jun 2007 03:19:53 +0200
with message-id <200706170320.05960.sune@vuorela.dk>
and subject line qmake, uic, moc and others as alternatives
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: qt3-dev-tools
Version: 3:3.3.6-1
Severity: normal

Currently, qmake is an alternative that points to either qmake-qt3 or
qmake-qt4 depending on administrator preference.  But we have dozens of
packages in the archive that simply call "qmake" to build, and that is
going to lead to failures if someone ever decides to change that
alternative locally: Apparently, trying to build Qt3 packages using
qmake-qt4 and vice versa leads to a hard failure.

We could place the burden on those packages to fix their rules, but that
seems to be the wrong place in my mind.  Generally, handling
non-interactive "file processing" (build) tools through the alternatives
systems is a problem.  We don't do it with gcc, we don't do it with
python, we do it with java and that causes all sorts of problems.  With
qmake, it seems totally wrong because these programs don't do the same
thing: one works and one just fails.

What might work is a wrapper script like autoconf has, that looks at the
sources and decides which version to call.  I can't offer any advice on
how to detect the right version, but maybe someone has an idea.
Alternatively, one version should be the default qmake and there needs
to be a transition sometime.


--- End Message ---
--- Begin Message ---
Hi!

We currently don't consider this a bug, but a feature to actually have both qt 
versions installable.

if you want to be completely sure which one you use, you can either set PATH 
and/or QTDIR appropriately.

I am closing these bugs.

/Sune

Attachment: signature.asc
Description: This is a digitally signed message part.


--- End Message ---

Reply to: