Attila Csipa wrote: > In theory you just depend on the proper version of libqt4-dev, but it's > tricky as you might indirectly reference libs that are also newer in the > SDK/new PR so end up with a 4.6 dependency (or broken build)
Seems that we need to follow on this, as it is clearly desirable that developers could make use of Qt 4.5 on Extras packages _now_. (And Qt 4.6 if we ever update again the autobuilder to 4.7; not that I am saying we should). Basically, these are the problems I've heard that happen when targeting libqt4-dev and submitting to the autobuilder: 1. Even though your application does not use Qt 4.6 API, autobuilder creates a dependency to Qt 4.6 instead of Qt 4.5. A possible explanation is that some macros, templates, MOC, etc. when using QT 4.6 headers expand to Qt 4.6 newly introduced symbols thus causing the final binary to have dependencies to Qt 4.6 libs. 2. There's at least one package that uses only 4.5 functions save for one single network-related function which comes from 4.6. Thus the final dependencies are detected as: libqt4-core >= 4.5, libqt4-gui >= 4.5, ... libqt4-network >= _4.6_ . This could cause potential problems with certain very Maemo specific ;) package manager's algorithms. 3. Qt Desktop guarantees that an application built under Qt 4.5 headers is binary compatible with Qt 4.6 libs. I'd like to know if we can guarantee that an application built under Qt 4.6 headers but using no Qt 4.5 introduced APIs would work under Qt 4.5 libs. If we can find fixes for all the above problems, we could use the same system we currently use for versioning Gtk+ packages dependencies for Qt applications (aka squeeze devkit .symbols files). Problem 2 at least seems to have a relatively easy workaround. Comments? Extra problems? WORKSFORME? Rants? Everything welcome. Javier. _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
