MSI installer for KDE4

Thu Aug 21 15:19:51 CEST 2008

Pau Garcia i Quiles said the following, On 2008-08-21 13:40:

> 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".
> 

Hi,
"Two" notes for the start, I mentioned them at Akademy:

> Not MSI installers necessarily, but standalone application installers  
> which only contain the application binaries and, maybe, some specific  
> dependencies.

Please note that we have much more modular packaging than this. E.g. 
applications are so often only bootstraps for real code, e.g. can be 20KB 
large as just contains main() function.
We do not link statically nor bundle graphical resources with every app. I'll 
try to explain this a bit more below.

> 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.

Someone would need to make research how this could compatible with mingw 
binaries, and how msvc and mingw binaries can live side-by-side. And whether 
anything like this could be built without need for installing msvc. Also note 
that people want to use cross-compilaton on Linux.

> 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. 

I wonder how asking the user to find deps by hand is better. It may be 
"familiar" but not better, just like crappy old car may seem to be "familiar" 
just for one week before you get accustomed with a shiny "unfamiliar" one :)

 > 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.

Could you please explain how this is different (except naming) than the KDE on 
Windows installer?
In fact features needed to achieve all this, are part of the installer, so 
perhaps what you request is to distribute parts of installers linked into the 
individual setup.exe files? I would be very interested to see a small 
bootstrap files that initiate dowloading of apps with dependencies, so only 
the files can be put in places like softpedia.com. The files can be like KLIK 
packages (http://klik.atekon.de/) bound to a given protocol in your browser so 
no need to use .exe files for that (the disadvantage is a need for performing 
one-time install of a KLIK-like protocol, what's of course not unfamiliar for 
the userbase since e.g. bittorrent clients use the same approach).

Let's note that MS has redistributable packages that most often do _not_ 
depend on other redistributable packages, perhaps because are linked so 
heavily that do not contain the dependencies. At most there are two levels of 
dependency, but I cannot even remember such case. It's the rule in MS and 
expected in most closed source offerings, and natiral that you have greater 
control over packages if there are no external dependencies you do not 100% 
cotnrol.
Even more, e.g. MS Office apps have been using their own (not the one coming 
from the OS) graphical layers/widget systems and who even knows this? I cannot 
see people running away scared from shops because of this :)

We can bundle almost everything with individual packages but in turn the 
packages would be big and their contents would be most likely redundant.
Note that closed source offerings even have self-contained binary blobs for 
graphics used in the apps, most usually compiled as windows resources, less 
likely kept as separate files. We have shared graphical resources. This shows 
the differences, that of course are here because of our much more open 
development model.

That said I remember many cases when I needed to quickly fix something, 
possibly on customer's end-user machine where only final release of KDE 
packages were installed. I was able to manipulate/upgrade/fix things _only_ 
using the filesystem tools, since
1) the installation is fully-file-based, resources, settings, plugins are all 
shared, and kept in stuctured dirs, outside of the Windows Registry, and in 
most cases dealing with UIDs is not needed
2) the knowledge how to deal with things are this level already come from 
experience of using Unix environments; there are only minor differences like 
names of the library files.
That would not be possible or easy if the bianries were not well shared.

> 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, 

i.e. is it too well designed, so they are scared? Could you provide any 
rational reasons?

Perhaps you propose better defaults or/and installation profiles like distros 
already do (e.g. minimal installation, office, full...)?

The installed for sure does not install "everything", at least IIRC. I believe 
we do assume that there's just good balance between installing minimal set of 
depenencies (that allows you to add new applications easier), and full install 
(aimed at developers which OTOH makes your kde directories heavier).

> 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).

CD/DVD/FS medium could be picked as the installation source. E.g. we could 
have separate DVD with simply few-click installation process. User would not 
be asked about settings if not really necessary. It's a good design prectices 
in for any app.

> 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

Perhaps you have issues with the GUI of the installer, in terms of usability 
(then such improvements can be made as the installer is very actively 
maintained - and kudos for this to the Team!), not about the whole idea which 
is exactly the same now, you only use different names (or paths) for the same 
things.

Finally, would you be interested to take part in the development process of 
KDE on Windows?

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)