On Thursday 30 July 2009 23:40:11 Scott Barninger wrote: > On Thursday 30 July 2009 05:27:34 pm Eric Bollengier wrote: > > Le Thursday 30 July 2009 23:24:26 Scott Barninger, vous avez écrit : > > > On Thursday 30 July 2009 05:06:11 pm Kern Sibbald wrote: > > > > On Thursday 30 July 2009 22:25:15 Felix Schwarz wrote: > > > > > Alex Ehrlich schrieb: > > > > > > * Are there any future plans for official or "semi-official" RHEL > > > > > > rpms (rpms-contrib-fschwarz is empty and no 3.0.1 was present, > > > > > > too IIRC)? > > > > > > > > > > I was abroad for quite a while with a *bad* internet connection so > > > > > I could not update these earlier. Compiling Fedora+CentOS is often > > > > > a challenge because Fedora tends to use the latest+greatest > > > > > versions which even few developers here test and CentOS has old > > > > > libraries which might need special treatment (see all the threads > > > > > about bat not building with QT 4.2). > > > > > > > > Actually, what we released with 3.0.2 does not seem to compile on Qt > > > > 4.2, but it does compile on 4.3.4, so I will be changing the > > > > documentation to require at least 4.3. > > > > > > I thought Trolltech's promise was compatiblility within "major > > > releases"? So 4.2 to 4.3 is a major release? > > > > Yes, all 4.2 should be compatible with 4.3, but all 4.3 isn't compatibile > > with 4.2... Some bat features are using QT 4.3. > > Ah, then it is "our bad" so to speak? As a friend of mine was fond of > saying, "Is the juice worth the squeeze?" Are those 4.3 features worth > breaking backward compatibility so that we are contemplating re-packaging a > large software package like QT with our releases just to make our > application work? This doesn't bode well in my mind for stable releases.
This crept in because the developers are all working on Qt 4.3 or Qt 4.4. I don't think we actually used any 4.3 features in bat -- in any case, once you are on a particular version it is easy to put in backward incompatibilities, if nothing other than when editing the ui files (GUI builder), it may put in a default or you happen to set a margin on a widget to make it prettier and low and behold, that generates new code (the .ui files generate c++ code) and you now have a dependence. I have suggested to the developers that they all work of the depkgs-qt version of Qt. This will give us a lot more control and ensure us that no higher version dependencies creap in. Since I am building on Qt 4.3, and I use bat, it guarantees it will build there. Over time, we will be moving up, so this will be a moving target, but now that we have identified the problem, I believe (hope) we have it under control. Kern > > > > > If you want a version that *does* work with bat, > > > > download the package in the depkgs-qt area > > > > (depkgs-qt-28Jul09.tar.gz). When you detar it, do the following: > > > > > > > > cd depkgs-qt > > > > make qt4 > > > > > > > > then when you build Bacula, either source the qt4-paths file in > > > > depkgs-qt or execute them directly before building, and eliminate any > > > > code in the .spec file that resets the QTxxx environment variables. > > > > With that, you should be able to build most distributions with Bat -- > > > > providing you want to. > > > > > > > > Best regards, > > > > > > > > Kern ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
