[Development] Online installer no longer lets users choose between Qt 5.3.0 and Qt 5.3.1

[Sze Howe Koh]

On 7 July 2014 15:10, Koehne Kai <Kai.Koehne at digia.com> wrote:
>> From: development-bounces+kai.koehne=digia.com at qt-project.org
>> [...]
>> 1) Developers who face regressions (not just testers) are now in an awkward
>> position, and need to install an extra copy of Qt Creator (see
>> below)
>
> Right, that's the main drawback. We could maybe have a 'Show all' section in the settings dialog or so that would show/hide such patch level releases though ... will bring this up with the Release Team.

Thanks!


[...]
>> No. When running an installer (online or offline), Qt Creator is a compulsory
>> component (although Qt itself is non-compulsory). I remember someone
>> saying that Qt Creator is made compulsory because of interdependencies
>> between the Maintenance Tool and Qt Creator.
>>
>> What are these dependencies? I'm willing to have a go at reducing this
>> coupling, if I know where to look. I believe one of them is for the installer to
>> register "auto-detected" kits. Instead of having the installer perform this
>> registration, would it make sense for it to simply add a "search path" to a
>> global Qt Creator config file, and let Qt Creator search for and register new
>> copies of Qt at startup?
>
> Registration of Qt versions, kits, and toolchains is indeed the primary problem. We call Qt Creator's sdktool.exe in the installation/deinstallation scripts of the Qt versions & the mingw toolchains .
>
>  I'm not sure doing too much (file system) magic on Qt Creator startup though is the right thing to do, since it will slow down every launch.

Perhaps Qt Creator could check to see if a path is already in its list
of registered versions/kits/tools, before scanning the physical
location?


> Alternatives that have been discussed in the past:
>
> 1. Move the sdktool.exe out of the Qt Creator package, into a separate one, and only make this one mandatory. That means though we'd need to ship separate Qt libraries for this tool only, effectively increasing the size of a 'default' installation.
>
> 2. Don't deregister/register toolchains and kits in the qt packages, but in separate virtual (i.e., hidden) packages that are only installed if both the resp. Qt version package and the Qt Creator package gets installed (AutoDependOn in IFW speak). This will only be a workaround though for new packages ... already released qt versions will still have a hard dependency on Qt Creator.
>
> 3. Accept the fact that, if people first install a Qt version / toolchain and _later on_ install Qt Creator, the toolchain & Qt version won't show up.
>
>
> I think both 1. and 2. are be feasible ... 3. might end up in more bug reports / annoyed users than the current 'forced' installation, so I'm personally not keen to implement this.

Agreed, #3 sounds like swapping one set of issues for another.

#1 makes a lot of sense; sdktool could be considered an inseparable
part of the MaintenanceTool.

I'm less familiar with #2 as I haven't implemented package managers
before; would this option increase the risk of repository corruption?
(Example: https://bugreports.qt-project.org/browse/QTIFW-519)


Regards,
Sze-Howe