On Friday 24 July 2009 14:40:35 Dirk Bartley wrote: > Greetings > > My $0.02. > > Some of the recent issues is that I just purchased a new computer :-) > and am using ubuntu for the first time. > > My experience to date is that the version of qt that development occurs > on is "most likely" not the issue. The issue is designer. If designer > had a mode of "save as version", life would be sooooo much simpler. I > could keep my up to date version and all the non bleeding edge distro > users would be kept happy. > > There's very little difference between the qt versions in terms of code > that I would use that could/should cause any issues. It's just designer > causing heartache so far. I'll admit I neither read nor track qt > changelogs. If I did use some new feature in terms of code it would be > quickly recognized and I could undo that change but I doubt that would > happen. > > What I'm considering doing is compling an older version of qt on my > system but not installing. Then point designer that I use during > development to the older version. I'd like to try this and see if it > solves alllllll of our portability issues between distributions. I'm > betting it will.
Yes, I think that is a good solution that will surely fix the majority of the problems, if not all. In fact the problem I ran into building it here on 4.3 was due to designer, and I simply edited the .ui file by hand and removed the problem code, but that isn't always so easy to do ... The rest, I think we can deal with as you say on a case by case basis ... Thanks. Kern > > Dirk > > On Fri, 2009-07-24 at 13:56 +0200, Kern Sibbald wrote: > > Hello, > > > > We will take the issue of RHEL 5.3 into consideration. Currently I am > > 99% sure that 3.0.2 does build on RHEL 5.3 -- I haven't tried the current > > SVN though where some of the more "modern" GUI features were added. > > > > It is always possible to link bat against the depkgs-qt code or any older > > version of Qt, but it not so convenient now that bat defaults to shared > > objects ... > > > > We will try to make some reasonable compromise between adding new GUI > > features and the ease of building. > > > > Kern > > > > On Friday 24 July 2009 13:27:15 Alex Ehrlich wrote: > > > > there always is a distro that uses old QT libs... > > > > > > Yes, but not always this "old" distro is the latest version of the > > > major server one ;-). > > > > > > But anyway, I know too little about Qt to comment on the topic whether > > > there are new features in 4.3+ over 4.2 that are *really* needed for > > > bat (or improving bat *significantly*). Being mostly a Windows guy > > > actually, I just know that my last database applications (i.e. > > > "business" like bat is, not "fancy DirectX10+" neither "advanced > > > security") were built in 2008 to work on Windows 95 (among other > > > versions of Windows -- up to Vista)... > > > > > > However, I admit that building bat statically is an option > > > (specifically for Redhat it would probably mean just a "huge" rpm built > > > by packagers, i386+x86_64). > > > The problem here is that server distributions do provide updates (e.g. > > > security) to system libraries sometimes, including Qt, but maybe for > > > "statically built applications considered trusted" like bat it is not a > > > critical issue. > > > > > > Alex > > > > > > Marc Schiffbauer wrote: > > > > * Alex Ehrlich schrieb am 24.07.09 um 11:00 Uhr: > > > >> Hello, > > > >> > > > >> Maybe you find possible to keep bat working with Qt v 4.2? I really > > > >> hope that bat does not use 4.3+ features extensively, and at least > > > >> one widespread server distro (RedHat/CentOS latest v 5.3) uses 4.2 > > > >> (4.2.1 currently). > > > > > > > > If you distro is too old then you could build qt statically into > > > > bat. > > > > > > > > Otherwise you could never use new QT features because there always > > > > is a distro that uses old QT libs... > > > > > > > > -Marc > > > > > > ----------------------------------------------------------------------- > > >---- --- _______________________________________________ > > > Bacula-devel mailing list > > > Bacula-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/bacula-devel > > > > ------------------------------------------------------------------------- > >----- _______________________________________________ > > Bacula-devel mailing list > > Bacula-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bacula-devel > > --------------------------------------------------------------------------- >--- _______________________________________________ > Bacula-devel mailing list > Bacula-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-devel ------------------------------------------------------------------------------ _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
