Hi Caleb, Patrick I saw on the bug #113549 this was already mentioned but it slipped. The qwt lib does not require qt4, it can be built with either qt3 or qt4. This should be made optional on qt3/qt4 use in a usual way perhaps. I am afraid I have to raise this issue again, since because of hard dependence on qt4 we cannot issue an update to qtiplot - see bug #144286. Can you please do something about this? I may try it myself, although I am occupied with other stuff atm, so this will have to wait somewhat (plus I'll have to get familiar with the package :)). George
The problem is that it either depends on one or the other. It's not possible, as far as I know, to build it in both qt3 and qt4 modes. So it would require a separate package. I'm happy to support that, but I'm not going to personally use it in that capacity (supporting qt3), so I doubt I'll spend much time working on it.
Well, in general this is possible, but that'll take some trickery and will require a "switcher" - perhaps an eselect module. So, yea, in this caseI think it is easier to just issue a separate package. Do you think something like qwt-qt3-... would be fine? Of course this is not "symmetric", but then qt4 is "the future" and the -qt3 package will be a temporary plug, that'll be pulled when all its dependants migrate to qt4. If you are Ok with such naming we can try to proceed with that. I think I'll let Andrey Grozin deal with this, as he seems to be deep into qtiplot and its dependencies already ;). Andrey: Please try to adapt qwt ebuild to use qt3 and issue a new one named qwt-qt3 and try to use that for qtiplot. I think this will be the easiest solution. Please submit the qwt-qt3 ebuild to this bug (if you want to submit it to overlay too, that's fine, just let me or Caleb review it first here, on the bug). George
(In reply to comment #2) > Well, in general this is possible It isn't. Ebuilds using Qt3/Qwt5 would need to block the ones using Qt4/Qwt5 and vice versa. There's no way to express this (with current Portage versions).
In theory you could get by with making a qwt-qt3 package and using it, however, the end result is a library with the same sonames and versions as its qt4 counterpart, so the possibility of having them conflict at runtime would be an issue. If the library gets installed as libqwt-qt3.so, then we should be okay. Making a qt3 ebuild should be easy, since you just have to mimic the steps in the qt4 based ebuild (qmake, make, make install). Just make sure to rename the final library and that the embedded soname gets changed too, and all should be well.
(In reply to comment #4) > If the library gets installed as libqwt-qt3.so, then we should be okay. Taking account that it'll be more a temporary measure (to my expectations at least) and that we have relatively few applications depending on Qwt, so we won't run in a mass blocker fiasco, it would also suffice, if qwt and qwt-qt3 would block each other. From the maintenance point of view surely the easier way to go. :)
Hm, "qgrep -H x11-libs/qwt" shows the whole two packages using qwt and qtiplot is one of them. The other one is pyqwt and it apparently has no dependants, so I'd even argue that qtiplot may be the more "important" one.. So, well, technically speaking it would probably make more sense to have a "primary" version of qwt build against qt3 for as long as qtiplot needs that and transition when qtiplot upstream switches. The problem, of course, is that qwt-5 is based on qt4 and is already in the tree (and surely I like unnecessarily perturbing already committed stuff no more than anybody else). So, I am just not sure what is the best way to proceed here. Since we have only two dependants it may indeed be sufficient to simply make them blocking each other and not worry about renaming the shared lib. Of course the 2nd approach is the "more correct" one, but that would require adjusting qtiplot build as well. Although this will need to be done anyway, as its not a simple "rename the ebuild" update (for qtiplot). (In reply to comment #3) > It isn't. Ebuilds using Qt3/Qwt5 would need to block the ones using Qt4/Qwt5 > and vice versa. There's no way to express this (with current Portage versions). Sorry, I should have been more explicit I guess - it is definitely not possible to do it "the portage way", but you surely can screw around with building both "versions" in the same ebuild, installing them in some mangled locations, producing the switcher and, basically, delegating to a manual "subdependency" resolution (that is remembering to switch them back and forth at appropriate times :)). However in this case this will be a disaster rather than a "workaround". And just in case - I am in no way proposing this, just saying that in general it is possible :). George
Another possible solution is to use the qt3 and qt4 USE flags used in some other ebuilds, if both are set then build with qt3 and add an ewarn about it (or do it the other way around). Then check in the qtiplot ebuild if qwt was built against qt3. AFAIK upstream is transitioning to qt4 so this should be a temporary situation depending upon how long it takes them to finish updating their code.
Keep in mind that aside from the "number of packages relying on it", there's also the developer aspect of peoplew ho build using qwt. I certainly have local apps that use qwt in both the qt3 and qt4 aspects, so we want to try and minimize damage to end developers who may be using them for their own projects.
(In reply to comment #8) > Keep in mind that aside from the "number of packages relying on it", there's > also the developer aspect of peoplew ho build using qwt. I certainly have > local apps that use qwt in both the qt3 and qt4 aspects, so we want to try and > minimize damage to end developers who may be using them for their own projects. Well, if the developers are the primary intended audience for this package then the approach I outlined in comment #6 may not be that bad. They should be able to keep track of what variant is active and when to switch :) (and they can clearly enjoy the benefit of both versions available side-by-side). However, as this seems to be only temporary situation, implementing anything like that is probably way more trouble than it is worth.. George
Created attachment 101275 [details] qwt ebuild which can build qwt-5 with qt-3 OK, here is a simple change to the existing ebuild. With USE=qt3 it builds a qt3 version of qwt. Andrey
Created attachment 115119 [details] qwt-5.0.1.ebuild I added the qt3 flag to version 5.0.1. It works fine with QtiPlot 0.8.9.
I am about to start using qwt in my application which is in portage. The app is currently QT3 based and it will likely be later this year before it is migrated to QT4. Having a qt3/qt4 use flag is fine by me. In addition to this I also found that my machine appeared to have both qwt 5 and qwt 4 installed but only one libqwt.so link which was pointed to /usr/lib64/libqwt.so.5 which was of course build against qt4. When I switched this link to /usr/lib64/libqwt.so.4 I was able to build my qt3 app using qwt which at that point was now version 4.2.0. Just wanted to let you know that there were more than two qt3 apps where this is an issue. Have the use flag is an OK solution for me.
(In reply to comment #11) > Created an attachment (id=115119) [edit] > qwt-5.0.1.ebuild > > I added the qt3 flag to version 5.0.1. It works fine with QtiPlot 0.8.9. Why this ebuild is still not in portage? I was not able to build qtiplot without it! qwt-qt3 - doesn't help at all. What is the reason to have it in portage? If I would use qt4 I would use qwt against qt4 only. But for now qt4 is unstable and even pyqt4 doesn't work. So what the reason to have both packages qwt an qwt-qt3 ?
qwtiplot just needs its deps updated: || ( x11-libs/qwt-qt3 =x11-libs/qwt-4* ) Then all will be well.
Why is this bug not closed yet? There are qwt and qwt-qt3 in the portage tree.
agreed, should be fixed now.
