Martin Loschwitz <madkiss@madkiss.org> writes: > On Sun, Feb 02, 2003 at 01:46:41PM -0800, Brian Nelson wrote: >> >> In that case, why not just remove libqt3-dev and have libqt3-mt-dev >> provide it? I doubt there's a single Qt application that would break >> because it was compiled with the threaded version instead of >> non-threaded. >> > Applications which have been linked against libqt would not stop to work, > but think of applications that have the "-lqt" ld option still hardcoded - > they would fail to compile. That's an upstream problem though, and it's easy enough to fix in a Debian package. > As said, dropping unthreaded Qt3 can be an option - after sarge > released. True. But having both libqt3-dev and libqt3-mt-dev is confusing and a little messy. Plus, programs that use the Qt plugins are annoyingly chatty because they apparently find 2 versions of the plugins. I'm not sure how accurate of an estimate this is, but: $ grep-available -F Depends -s Package libqt3\ Package: libqt3-psql Package: libmico-qt2.3 Package: mq3 Package: doxygen-gui Package: qcad Package: libqt3-odbc Package: kascade Package: kmatplot Package: xxdiff Package: libsoqt20 Package: djview Package: hpoj-xojpanel Package: tulip Package: libqt3-mysql Package: view3ds That's not many packages that are linking against libqt3. It shouldn't be hard to fix them and do away with the single-threaded version. -- My secret to happiness... is that I have a heart of a 12-year-old boy. It's over here in a jar. Would you like to see it?
Attachment:
pgp1BIgvaWA8s.pgp
Description: PGP signature