MSI installer for KDE4

[Patrick Spendrin]

Pau Garcia i Quiles schrieb:
> Quoting "Aaron J. Seigo" <aseigo at kde.org>:
> 
>> Hello Hamed ...
>>
>> On Thursday 21 August 2008, you wrote:
>>> Is (or will be) there any MSI installer for kde4 on windows?
>> I really don't know, but I'm CC'ing the kde-windows team because   
>> they probably
>> *do* know ;)
> 
> This is something I'd like to see. There was some chatting about this  
> at  aKademy and I was reading more about side-by-side assemblies  
> before writing but here comes a "mind --dump".
> 
> Not MSI installers necessarily, but standalone application installers  
> which only contain the application binaries and, maybe, some specific  
> dependencies.
> 
> I think what we should do is have redistributable kdelibs, kdepimlibs,  
> etc binary packages mimicking the Visual C++ Redistributable Packages  
> Microsoft makes available for Visual C++. Using side-by-side  
> assemblies (SxS, http://msdn.microsoft.com/en-us/library/aa376307.aspx  
> ), these libraries would be shared by all KDE applications and thanks  
> to the versioning capabilities SxS provides, it would even be possible  
> to have KDE 4.1 and KDE 4.2 applications (for instance, Parley from  
> 4.2 and Kate for 4.1) without kdelibs 4.1 and 4.2 clashing.
> 
> How would this work (at least in my mind :-) ? You would only download  
> an application and the installer (NSIS, MSI or whatever it uses) would  
> look for the libraries it needs.
> 
> Take, for instance, KWord. The KWord installer would only contain the  
> KWord binaries and 3rd party dependencies specific to KWord. When the  
> installer is started, it would look for KDElibs 4.1 (or 4.2, I don't  
> know then KWord plans to release) and KOfficeLibs 2.0. If KDElibs 4.1  
> and/or KOfficeLibs 2.0 are not found, it would tell you it needs the  
> "KDElibs 4.1 redistributable package", exactly the same way  
> applications compiled with Visual C++ 2005 and 2008 do now if you are  
> on Windows 2000 or XP. It could even offer you to download and install  
> the package for you. This "KDElibs 4.1 redistributable package" would  
> then contain KDElibs 4.1 and its 3rd party dependencies.
> 
> My point is the current installer works very well because it resolves  
> dependencies and installs everything but it's not what a Windows user  
> is used to and IIRC, offline installations need you to essentially  
> mirror the WinKDE repository and tell the WinKDE installer where the  
> mirror is (not exactly intuitive for the average Windows user).
> 
> Summarizing, what I propose is:
> * Have redistributable packages for kdelibs, kdepimlibs and  
> kofficelibs, each one of them including its third-party dependencies
> * Use side-by-side assemblies and make kdelibs, kdepimlibs and  
> kofficelibs be shared assemblies
> * Standalone installers for applications, including the application  
> and the 3rd party dependencies specific to that application
> 
> Comments?
> 
ok, after reading all your questions and fears, here is what I think 
about it:
As Christian and Jaroslaw pointed out, the exact way to install or 
package is irrelevant - whether the installers are called nsis or msi or 
kdewin-installer, whether we build with mingw or mingw cross-compiled or 
msvc is a question of believe (well a bit work and money too).

The problem is somewhere else:
We haven't come over to a good idea how to ship KDE.
We currently ship KDE in the packages according to KDE modules.
This has several disadvantages:
- We can't ship single applications.
- There are a lot of third party libraries which each have their own 
package - each has its own version, each has its own binary 
compatibility etc. (think of dll hell)
To illustrate this a bit here is a small bug:
https://bugs.kde.org/show_bug.cgi?id=169475
It comes from mixing two different versions of KDE (4.0.83 and 4.1.0) 
which seems very likely to break.

Thats why my proposal is something else:
We decide to give a version number to the following packages:
complete win32libs
complete qt
complete kdesupport
kdelibs, kdepimlibs and kdebase-runtime
The version number can be made up like K.D.E.XXXX.compiler
where K.D.E is the KDE version number and XXXX is a version bumped when 
any underlying libraries are changed (e.g. for security reasons) and 
compiler is a name for the compiler used.
This meta-package should be shown in the installer so users can be asked 
for its version in bug reports, it should be rebuildable (shouldn't be 
to much a problem) and it can be installed by all possible installers 
thus. All KDE applications should be build on top of one specific 
version of this meta package.

If you are all ok with that, I will try to find a working solution to 
test with the upcoming KDE 4.1.1 or 4.1.2 release.
I will implement some changes to make the build of single applications 
possible too.

regards,
Patrick

-- 
web:                 http://windows.kde.org
mailing list:        kde-windows at kde.org
irc:                 #kde-windows (irc.freenode.net)