Re: qt + gl + problems + etc...
Sounds great. Though I'm sure you've thought of it, maybe have one of those
"notes" that dpkg uses when a user install libqt-gl, saying VERY LOUDLY that
they'll have to change the linking option for any qt-gl apps, and emails it
to them if they have their priority level too high. Other than that (and the
fact that my home desktop can't install 2.2 yet, missing kdelibs3
>=4:2.2-cvsfoo-1 in unstable) and I'm *really* liking this new kde :-) I've
been running the alpha at work for the last week (from people.debian.org),
and aside from konq's tendency to wonk out at seeminly random places once a
day, it's very nice. Please keep up the good work!
On Wednesday 27 June 2001 17:57, Ivan E. Moore II wrote:
> 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
> 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?