Re: qt + gl + problems + etc...
well..doing a debconf warning won't do any good for the maintainers of
the packages. It'll only annoy any users who install the library. I'm
expecting that people will file bug reports rather quickly that apps fail and
the maintainers will come yell at me and all will eventually be good.
new maintainers will find out by reading documentation or asking me.
as for 2.2...beta1 is really nice. kdelibs is in incoming and kdebase is
on it's way up right now.
On Wed, Jun 27, 2001 at 09:10:45PM -0600, David Bishop wrote:
> 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!
> Many Thanks,
> 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
> > 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
> To UNSUBSCRIBE, email to firstname.lastname@example.org
> with a subject of "unsubscribe". Trouble? Contact email@example.com
---end quoted text---
Ivan E. Moore II
GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645 8141 90BC E0DD