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

Re: Announcing the availability of first Qt 3.3 packages

Dominique Devriese <dominique.devriese@student.kuleuven.ac.be> writes:

>> One of the reasons I'm so ornery when it comes to the Debian Qt
>> packages is that much of this stuff was discussed before the split
>> and there seemed to be a consensus that there were a lot of problems
>> with it, yet it was done anyway without heeding any of the advice.
> You don't happen to have a link around, do you ?

There's a massive thread here:


A little more here:


There's probably more but I don't feel like looking.

>>> For another thing, Qt assistant is not only a development tool
>>> either.  Many Qt apps use it to display their documentation.  You
>>> would require every user of such apps to install the entire
>>> development package.
>> Really?  I was not aware of this.  I don't think it would matter
>> much though since I doubt any users other than Qt developers are
>> aware of the assistant, and the documentation is in html format
>> readable by any web browser anyway.
> It's not a matter of being aware of them.  The fact is that if you
> press "help" in some qt programs, they call the assistant.  Users need
> it.  period.

Well in that case it clearly belongs in libqt3c102-mt.

>>> You also seem to ignore non-multithreaded use of the qt libraries,
>>> even though there are still applications depending on this.
>> Well, there are only 2 packages in Debian still using them (I filed
>> bugs to fix all of them)--one appears to have a dead upstream and
>> the other has a negligent maintainer.
> Non-multithreaded use is discouraged and will be removed in Qt 4.
> There's no reason for Debian to remove it earlier.  I consider your
> bugs invalid.

The libqt3-dev package description, written by Madkiss, says:

 WARNING: The nonthreaded version of Qt3 is considered deprecated and
 may disappear anytime in the future. Please use libqt3-mt instead
 (Read README.Debian for instructions).

Non-multithreaded use is already discouraged, at least in Debian...

Furthermore, we are not compelled in any way to include it.  When
building Qt, you get a choice, and that choice is multi-threaded by
default.  You don't get both.  Qmake is designed more or less to adapt
to the currently installed Qt--if it's built mt, qmake creates makefiles
for mt.  I don't see any reason why we need to have both versions if no
software in Debian uses non-mt.

>>> Summarizing: Qt is a very complex package, and there are good
>>> reasons for most, if not all split-ups.
>> I'm still unconvinced of that.
> Fine, I'm not going to keep arguing with you over this.  IMHO, as
> you've demonstrated above, you don't seem to know Qt thoroughly enough
> to be able to understand the need for the structure of its packages.

I'm confident I know Qt very well for standard application development
and I don't see anything above that demonstrates otherwise.  Just
because I want to change the package around (actually, it's more
reverting it to the way it was pre-madkiss), does that make me

I've already admitted to not knowing anything about embedded stuff.
Which is fine no one actually uses all of Qt, so no one is qualified to
be the sole maintainer of the package.  It should be group-maintained.

>>> If you want to help, it would imho be more useful to send Martin
>>> patches for some of the real problems, as he has already requested
>>> often.
>> I have in the past, but they've been rejected (because Ralf Nolden
>> is a stubborn flaming nitwit IMNSHO).
> Any link on that ?


You win again, gravity!

Reply to: