Ok...so with kde 2.2 mostly uploaded (some bits already installed) to sid I
turned focus to QT again especially since I've personally had many crashes
of konsole due to the whole GL bit.
so this lead me to a immediate solution. I still do not like this solution
however this is one that I am comfortable in sticking with if a proper
one does not arise before woody's release.
so your asking...what's the solution???
well...a libqt2-gl package...but not like before. I have created a completely
seperate source package (qt-x11-gl) which builds 2 packages: libqt2-gl and
libqt-gl-dev. The actual qt library it creates also has been changed. Instead
of it providing /usr/lib/libqt.so.* I've renamed the library to libqt-gl so
that it can co-exist with a normal (non-gl'd) qt library.
So..what does this do for everyone you might ask?
allows packages that do not need the GL bits of QT to not have to deal with
a library with them compiled in nor the issues surrounding QT + GL + threads.
(short answer on this...flash plugin works, no more konsole crashes, etc...)
This also allows for applications that do need GL support to still exist within
the distribution. (oh yea..and the pure_virtual problems *should* go away)
So..what's the drawbacks you might ask?
1: (obvious) yet another package (well 2)...not really that big of a deal
2: anyone who wants their package to link to the GL'd version of QT *must*
modify their build process to link to libqt-gl instead of libqt.
( "-lqt-gl" instead of "-lqt")
Overall I think this will be a good solution until someone comes up with another
better solution. I'm sure I'll get several bug reports from people saying
their GL based apps broke and then I'll hear them gripe when I tell them they
need to install libqt-gl-dev and modify their source.
any major issues before I upload the new packages?
Ivan
--
----------------
Ivan E. Moore II
[EMAIL PROTECTED]
http://snowcrash.tdyc.com
GPG KeyID=90BCE0DD
GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645 8141 90BC E0DD
