Re: Announcing the availability of first Qt 3.3 packages
Dominique Devriese <devriese@kde.org> writes:
> Brian Nelson writes:
>
>>>>> 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.
>
> Yeah, firstly, I've prolly been too harsh above. Sorry. I guess it's
> my natural geek tendency to flame coming up :s
>
> What I was talking about is that you didn't seem to know what Qt
> Assistant is intended to be used for,
Well, I know what it is used for--I use it all the time when doing Qt
development. I never realized any application actually made use of it
to display their own documentation. A quick check of qt3-assistant's
reverse dependencies shows that nothing outside of Qt depends on
qt3-assistant in Debian, so you can surely understand my ignorance.
> what qt-apps-dev could be used for, even when the package description
> stated it pretty clearly etc,
Hmm, I wonder if I was thinking of another package description. The
qt3-apps-dev one does seem pretty clear (though the package name is
still confusing). It still seems like an odd package to me; it sounds
like it could suitably be integrated into another package.
> and the radicalness of your proposals.
>
> About the issues we were discussing:
>
> * get rid of non-mt packages
> -> Could save quite some buildd time, but might upset some people
> still depending on it. I wouldn't do it yet for Qt 3.0
> personally.
> * get rid of embedded stuff
> -> prolly not a good idea, you seem to have changed your mind here
> too or I misunderstood you in the first place.
> * get rid of libqt3-compat-headers
> -> I disagreed, but Ben convinced me.
> * move a lot of dev stuff into one -dev package
> -> Don't really like the idea, since it makes all people install
> more stuff they don't need, and I still seem to miss the advantage.
I think you looked at the changelog entry of my Qt package and assumed
everything I did was for a good reason. In actuality, the changes were
noted to record the damage I did as well as the things I actually
thought were good ideas. Sorry about the confusion. To clarify, here
are my following proposals:
------------------------------------------------------------------------
* Remove the non-mt packages.
Rationale: No package[1] in Debian depends on it. It only serves to
confuse people which package (libqt3-dev or libqt3-mt-dev) to use, and
bogs down the buildds.
Result: Removes libqt3-dev, libqt3c102, libqt3c102-mysql,
libqt3c102-odbc, libqt3c102-psql, libqt3c102-sqlite
Removing the non-mt packages would only potentially break 3rd-party
software that uses the non-mt libraries. This software includes:
- Old Qt2.x era software whose configure scripts are not capable of
detecting the mt version. These scripts were already broken by
the move from /usr/share/qt -> /usr/share/qt3, so it's not worth
worrying about.
- Commercial software linked against the non-mt version as a shared
library. Such software is likely quite rare since normally
commercial software is statically-linked. Users of any such
software, if it exists, should bash the vendor to fix it.
- Software compiled on other distributions but run on Debian. This
is another unusual case that is dependent on whether other
distributions use the mt or non-mt libs (the GCC version used
could break compatibility anyway). I have not investigated this
at all, but I suspect most other distros compiled with GCC 3.x use
the mt libs as well, so this situation would be moot.
Also, there's another potential solution to these problems: create a
libqt-mt.so.3 -> libqt.so.3 symlink and have libqt3c102-mt provide
libqt3c102. Making stuff reentrant seems, in theory to me anyway, to
not break binary compatibility. For my own amusement, I just tried
running the qterm in Debian with this symlink and it seemed to run OK.
I have no idea if it would work reliably for other software though.
History note: I am largely responsible for the software in Debian
uniformly using the mt libs. It was decided by Madkiss (and others?)
a year or two ago to deprecate the non-mt libs in favor of the mt
libs. I strongly supported this stance, and at Madkiss's, errr,
goading[2], I filed bugs with patches against every package in Debian
depending on libqt3/libqt3c102.
[1] OK, vipec and qterm do depend on libqt3c102. vipec has a patch that
is waiting for the maintainer to apply it, and qterm and old and
should just be removed.
[2] http://lists.debian.org/debian-devel/2003/02/msg00144.html
------------------------------------------------------------------------
------------------------------------------------------------------------
* Consolidate the headers (compat and otherwise) and other critical
build tools into the libqt3-mt-dev package
Rationale: It's simpler, breaks fewer things, and gives the -dev
package a clear purpose.
Result: Removes libqt3-compat-headers, libqt3-headers
My main reason for this proposal was for simplicity and consistency
with all other library packages in Debian. The space savings by
putting the headers in an arch-indep package are small.
Also, calc noted[1] a much better reason for merging the headers into
the dev package: having an arch-dep dev package and an arch-indep
headers package causes the two to get out of sync for some time after
an upload, causing FTBFS problems on other architectures. This is
probably the biggest reason why all other library packages in Debian
put the headers in an arch-dependent -dev package.
I also support placing the following executables in the -dev package:
qmake
lupdate
lrelease
uic
moc
This allows the -dev package to provide a minimal environment in which
to build virtually all Qt applications (which is exactly what a -dev
package should do, and what most people would expect it to do).
[1] http://lists.debian.org/debian-qt-kde/2004/06/msg00269.html
------------------------------------------------------------------------
------------------------------------------------------------------------
* Move other tools for development into the qt3-dev-tools package
Rationale: Provides a simple way for a user to install a full
development environment
Result: Removes qt3-apps-dev, qt3-assistant, qt3-designer,
qt3-linguist
The rest of the development tools can be placed in the qt3-dev-tools
package, so that a Qt developer may install this package to get a full
Qt development environment. These tools roughly include:
assistant
designer
linguist
as well as their support files.
Dominique Devriese pointed out[1] that applications may make use of
the assistant to display help documentation, in which case it may be
better suited in the libqt3c102-mt library package.
I believe the majority of users who do Qt development (i.e. those that
do more than just build Qt-using software) would want all of these
tools available to them, so there isn't a great need to keep them
separate.
[1] http://lists.debian.org/debian-qt-kde/2004/06/msg00284.html
------------------------------------------------------------------------
------------------------------------------------------------------------
* Put the translations and qtconfig in the libqt3c102 library package
Rationale: simplicity, should be installed for most users anyway
Result: Removes libqt3-i18n, qt3-qtconfig
qtconfig is a tool that is very useful for configuring the user's Qt
environment, and consequently I think it should be available to any
user who has the Qt library installed. Note it's a relatively small
binary (~220K). In my experience, many users are not aware of
qtconfig because it's not installed for them by default, but find it
very useful once they have discovered it.
The translation files are useful to non-English speakers, and are also
quite small (~20K each * 8). I don't see any reason why they
shouldn't also be included here.
------------------------------------------------------------------------
------------------------------------------------------------------------
* Remove the compat tools
Rationale: No one needs them
Result: Removes qt3-dev-tools-compat
Qt3.x has been out since 2001; any application that has seen
development since then has most certainly already been ported to Qt3.
I don't see any reason for them to be distributed in Debian any
longer.
------------------------------------------------------------------------
Note that I did intend to make a proposal regarding the embedded tools.
I merely have not yet investigated them. Since they seem quite small
(~280K), I believe qt3-dev-tools would make a nice home for them.
Comments, criticisms, etc. welcome.
--
You win again, gravity!
Reply to: