Good point! Maybe, use the debconf warning, but attach it to a "libqt-gl-dev" package, that those who are going to be compiling their own software will need to install, but a normal user wouldn't. I'm just trying to make your job easier :-) It's not like you don't have a ton of emails to wade through anyways......
As for beta1, I'm looking forwards to it B-) David On Wednesday 27 June 2001 20:46, Ivan E. Moore II wrote: > 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. > > Ivan > > 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, > > > > D.A.Bishop > > > > 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 [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact > > [EMAIL PROTECTED] > > ---end quoted text---
