Kai Koehne

Qt Installer Framework 2.0 Released

Published Tuesday April 7th, 2015
17 Comments on Qt Installer Framework 2.0 Released
Posted in Qt Installer Framework, Releases | Tags:

We’re happy to announce version 2.0 of the Qt Installer Framework.

The Qt Installer Framework is a set of tools to provide offline and online installers on Windows, Linux, and OS X. It’s focused on the requirements of the Qt installers, but is flexible enough to be used as an installer and updater for other applications, too. See the documentation for an overview of its features. The Tutorial section shows you how to create a simple offline installer.

Version 2.0 contains a whole lot of bug fixes and new features: See the ChangeLog for the full picture. The reason to bump the major version number is, however, that the framework itself is now built with Qt 5 instead of Qt 4. Among other things, the scripting backend has been ported from Qt Script to the Qt QML module, while maintaining full compatibility for the scripts. The port to Qt 5 also allows you to run fully scripted installers without any GUI.

We have been striving to keep compatibility for existing 1.6 installations. That is, you should be able to update existing 1.x online installers transparently with ones built with 2.0.

You can find precompiled and source packages in your Qt Account and on qt.io.

Special thanks go to Christoph Vogtländer, Sze Howe Koh, Ray Donnelly, Tasuku Suzuki, Takayuki Orito, Sascha Cunz, Zhang Xingtao, Sergey Belyashov and Cuoghi Massimiliano for contributions.

Do you like this? Share it
Print this pageEmail this to someoneShare on LinkedInShare on Google+Share on FacebookTweet about this on Twitter

Posted in Qt Installer Framework, Releases | Tags:

17 comments

Scorp1us says:

Yay! But can the installer framework make deb/rpm//etc packages for use with normal package managers?

Kai Koehne Kai Koehne says:

The installer framework features it’s own metadata format, which isn’t directly translatable to deb/rpm et al. I’m afraid any such translation would work only for the most trivial packages.

The difficulty isn’t usually the exact format, but to get dependencies, paths … etc for various distributions right. I personally had good experience with http://openbuildservice.org/ to generate packages for different Linux distributions.

Clement Wong says:

Kai, well couldn’t deb/rpm packages can still be installed as standalone software under /opt without depending on any system packages.

Kai Koehne Kai Koehne says:

Right. But the strength of the installer framework, and package manager’s in general, is the dependency management + execution of setup / cleanup code when packages are installed and removed (full scripts, in the IFW case). And these parts cannot trivially be converted to other packaging formats.

If you ‘just’ want a dump rpm/dpkg/ package that does nothing but extract the archive to /opt/ I think it’s trivial to create these with native tools, so you don’t gain much by writing a package.xml that then get’s converted to a native package format.

Máté says:

I was always curious why doesn’t Qt ditch some of it’s own technologies and depends on/contributes to CMake-related projects?

Qmake seems duplicates most of CMake’s functionality, but the latter seems far more capable, specially when used alongside various modules. The effort put into this framework could reach more people I think if it were placed into a CPack module.

The question could intiate a long argument, but what are the main motives behind Qt not using CMake? The jom.exe utility could also be ditched, if project’s own makefiles were ported.

Maurice Kalinowski says:

I think you are mixing up multiple things here.

First of all this blog post is about the Qt Installer Framework, not qmake or cmake.

However, historically qmake is way older than cmake and tailored towards its use-cases with Qt. Furthermore there is contributors from the community taking care of cmake support.

Both, cmake and qmake, create makefiles where you still need to invoke make/nmake. jom helps in parallelizing this step, having multiple compilations in parallel. Hence it is an additional tool, again not some replacement.

Lastly talking about cpack, there has been a contribution by Konstantin Podsvirov to use Qt IFW with cpack. See here for more documentation http://www.cmake.org/cmake/help/v3.1/module/CPackIFW.html

Violet Giraffe says:

No way. Cmake is TERRIBLE. Borderline unusable. Qmake, on the other hand, simply works.

Slartibart says:

Any plans on making it more “compact”? I realize that to have full Qt functionality one needs quite a bit of library code, but when just the installer itself becomes 16MB in size it is starting to get a bit silly (the installer often being significantly larger than the components being installed).

Maurice Kalinowski says:

@Slartibart
I can see you point for small “snippet” applications. In that case the Qt Installer Framework might feel too big and other alternatives can be more appealing.

However, if you are targeting use-cases like the Qt installers or big applications, which need an update mechanism, the capability to manage packages on your installation etc. then Qt IFW certainly is an option.

zack says:

Is this installer framework distributed with Qt framework installer too?

Kai Koehne Kai Koehne says:

The installers for the Qt Installer Framework are (of course!) also built with the installer framework. But we don’t ship the Qt Installer Framework so far inside the Qt online installer. Would you prefer that?

zack says:

I would prefer that the installer is shipped with every qt installation (I mean the Qt sdk; online and offline) Like the QtCreator is shipped with the installer.
All other doesn’t make sense for me. IMHO.

Juergen says:

Hi Kai,
does the new Installer Framework support command line support? This would be quite handy when you are working with server based installation of Qt.

Kai Koehne Kai Koehne says:

The Installer Framework does not offer a text-only GUI. However, what you can do is script your installer with the help of a controller script, and then launch it with ‘–script myscript.js –platform minimal’. This should work from e.g. a text console, too.

Dmitry says:

Hello.
Question regarding the licence. If we intend to extend IFW functionality (eg adding xml support), that involves modifying ifw sources (eg packagemanagercore.cpp). Is that allowed for commercial application (assuming publishing patches)?

Kai Koehne Kai Koehne says:

I’m afraid we can’t give legal advise here. But the Installer Framework is available either under LGPL v2.1, or LGPL v3, or a commercial license. You obviously need to meet the requirements of one of them :)

Jeroen Dierckx says:

I use an in-app call to maintenancetool –checkupdates to check for updates, which always worked very well.

Since I updated the (online) installation package and repository to IFW 2.0, the –checkupdates call seems to fail.

When I try in the console in verbose mode (maintenancetool.exe –checkupdates -v), I get “[0] create Error-Exception: “Installers cannot check for updates.”

Commenting closed.

Get started today with Qt Download now