MSI installer for KDE4

[Pau Garcia i Quiles]

Quoting Jaroslaw Staniek <js at iidea.pl>:

> 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

I don't understand what you mean

> We do not link statically nor bundle graphical resources with every app

I'm not proposing that. Icons, graphics, languages, etc would be part  
of the redistributable packages (kdelibs 4.1, kdepimlibs 4.1, etc)

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

AFAIK SxS is not supported by MingW.

MSVC2005 allegedly works under wine, although that is not the ideal solution.

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

Given that how many people are using Windows, it looks like "familiar"  
means actually "better" for many people.

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

Totally different

What you would have downloaded is a single application (KWord)  
installer which contains the application binaries, as opposed to  
generic installer which bundles nothing (the current KDE on Windows  
installer).

In case you are offline, you would install the KDElibs redistributable  
package and the KOfficeLibs redistributable package yourself, then  
KWord. With the current WinKDE installer, you would need to mirror the  
WinKDE repository, then tell the installer the location.

Offline installations would be as easy as dropping three files  
(kdelibs4.1_redist_x86.exe, kofficelibs2.0_redist_x86 and  
kword_2.0.exe) in one folder, then the user double clicks on  
kword_2.0.exe and he's done.

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

I don't really understand what you mean with linking or bootstrapping :-?

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

KLIK bundles the application and all its libraries and resources in a  
single package, it does not share libraries or resources. By using SxS  
we would save that, as applications needing the same libraries and  
resources would share them.

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

I would say they do not depend on other redistributable packages  
because they are "low-level" stuff, thus few possible "levels of  
dependency" are present.

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

Unfortunately with KDE we have lots of dependencies, so we are out of  
this scenario.

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

This is because the MS Office division is usually one step ahead of  
the systems (programming languages) division in regards to widgets and  
libraries. For instance: the ribbon UI was invented in Office, so  
there were no libraries coming from the VC++ people they could rely  
on, that's why it was necessary for them to bundle the UI libraries  
with Office.

> We can bundle almost everything with individual packages but in turn the
> packages would be big and their contents would be most likely redundant.

No need for this. What I propose is to bundle kdelibs, resources  
needed by kdelibs and 3rd party libraries needed by kdelibs in the  
kdelibs redistributable package. Same for kdepimlibs and kofficelibs.

kdelibs redistributable package = kdelibs binaries + kdelibs resources  
+ 3rd party libraries needed by kdelibs

We would then have standalone installers for the applications, which  
would contain the application binaries and resources, and the 3rd  
party libraries specific to that application. Third party libraries  
used by several applications would go to the kdelibs redistributable  
package (or kdepimlibs redist package, or kofficelibs redist package).

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

As I said before, they would be in the redistributable package, not in  
the application installer.

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

Certainly but IMHO being able to "hack" the installation is less  
important than having intuitive and familiar installers.

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

Too many options

When you want to install, say, Amarok, it automagically selects  
dependencies, which immediately creates a "WTF is going on!?" feeling  
into the user.

One easy way to improve this would be to have "fake standalone  
installers": you download a small amarok_online_installer.exe, then it  
shows you the Amarok logo, inspects your system and:
- internally the installer "thinks": "uh oh, this guy is not using  
KDE, I'll need to download the whole Internet and more", and goes for it
- the installer shows a friendly message to the user: "The installer  
is going to donwload Amarok from the Internet. This operation may take  
a few minutes, or considerably longer depending on your Internet  
connection" (this Windows message makes me laugh every time I read it  
:-)

It's still different from what I propose because this "fake standalone  
installer" would download everything (it does not contain the Amarok  
binaries) and I'm not sure it would allow coexistence of applications  
from two KDE versions (for instance, 4.1 and 4.2) without squashing  
the 4.1 libraries with the 4.2 ones. Yes, binary compatibility and  
all, but that means that, for instance, KDevelop would automagically  
have some new option I don't want/like/need just because Kate got  
updated.

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

It's not what I'm proposing and I don't really like that. I have not  
made any survey but I think people usually want to install a  
particular application, not a "minimal installation" or an "office  
installation" which may or may not contain the application they want.

>
> The installed for sure does not install "everything", at least IIRC.

I never said it installs everything

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

How is this related to my redistributable packages proposal? :-?

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

Why would I want to mirror the WinKDE repository, wasting space and  
providing an intricate directory hierarchy when I can do something as  
simple as dropping kde4.1_redist_x86.exe and parley_4.1.exe in a folder?

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

I think the installer is very good but not perfect. IMHO, the more we  
mimic the way users are familiar with to install applications, the  
more users we will have.

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

Of course. I have some notes I took at aKademy and will be sending a  
couple of e-mails, probably tomorrow.

WRT the redistributable libraries and the standalone installers, it is  
a considerable effort, so I will not pursue that path unless there is  
general agreement this is the way to go. Even if this agreement is  
reached, I'm pretty busy with another application until mid-September.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)