Per-app MSI-based installers

Kevin Funk kfunk at kde.org
Wed Jul 2 22:04:33 UTC 2014


On Wednesday 02 July 2014 20:53:14 John Layt wrote:
> *Puts on Devil's Advocate cape*
> 
> On 2 July 2014 19:02, Kevin Funk <kfunk at kde.org> wrote:
> > On Wednesday 02 July 2014 19:35:15 Boudewijn Rempt wrote:
> >> But honestly... Is that really large? In this day and age 100mb is not a
> >> lot of bytes to download.
> 
> For a user in the west who has a large hard drive and a fast internet
> connection and really wants that app?  Maybe not.  But for other users
> with slower links or old hardware or who just want to have a quick
> trial it could be a barrier. Saying you need to download another
> 100MB every time you want another KDE app no matter how small will
> just leave a reputation for being bloated. 

Currently, the "barrier" for people on Windows trying KDE applications is to 
find out that a) there *isn't* an installer for that particular application 
he/she wants, eventually find out that there is some central installer, go 
through that, select the correct packages and hope that everything 
downloads/installs correctly. I can completely understand that people are 
reluctant to go through that and instead just look for alternatives that have 
a "normal" installer and "just work".

Things like the KDEWin installer are unfortunately completely unexpected for 
the average Windows user. And before trying to force the Linux way onto them 
regarding package management, you first have to convince them that it is worth 
to learn it. (By showing off your applications via making it easy enough to 
install them.)

> While I'm not one for
> clinging on to supporting really limited hardware, we're also not just
> here to make life better only for the more well off (or at least I'm
> not).

You're talking about 100 MB of disk space in conjunction with "for the more 
well off"? Really, that's not an argument. Disk space *is* cheap. And I'm sure 
we can get the installer sizes far below 100 MB (stripping out icons, unneeded 
common data, etc.)

> We have the same argument on Mac where most apps are distributed as a
> complete bundle, but what about Android or iOS or Blackberry where
> users do get jealous of every MB that an app takes up? 

That's not really an argument either. That's desktop Windows vs. mostly 
tablet/phone OSes. And on these OSes the system even limits you in how to 
distribute the application (no inter-package library dependencies possible or 
similar)

> Will we build
> and support completely different packaging and distribution models on
> every platform?

Yes, because we want to make it easy for them to adopt KDE software. Otherwise 
we'll never gain traction on other platforms.

> Also, as a distributor, can KDE afford to host such large packages?
> Will our mirrors be happy if every app requires a 100MB+ bundle and we
> have 100 apps?  I know when it was proposed that Qt ship ICU on
> Windows and Android and Mac that the app devs were outraged at the
> thought of having to pay for an extra 10MB in every download, as well
> as the 30MB extra hard disk space used.

Regarding Qt and ICU: That's a library, where every MB counts. But we're 
talking about end-user ready application installers.

> >> And if I've learned one thing from struggling with cross-platform
> >> packaging
> >> is that it's never worth it to go outside the platform's conventions, at
> >> least for applications meant for regular users. That means, no cygwin,
> >> macports, fink, homebrew, kde-win installer or emerge. It also means, on
> >> Windows, that an installer is complete and includes everything including
> >> the right msvc runtime. It means no daemons, no running of apps like
> >> kbuildsycoca that are alien to the platform.
> 
> Completely agree on the daemons and the like, it's why I keep saying
> we should never use dbus or systemd directly in any apps.  All system
> integration and IPC needs to be abstracted. (*)  Also mostly agree on
> the bits about relying on things like Macports or Cygwin, they are too
> heavy and geeky for end user apps and prone to breaking in ways
> outside our control.  However, I don't think that prevents us from
> doing something small scale ourselves inside our installers to share
> libraries between our apps in our own install folder.
> 
> OTOH, having shared libs and individual app installers does open us to
> the eternal DLL hell of someone having two different apps installed
> that have two different version requirements for Frameworks, that's
> one scenario having fat packages helps avoid.
> 
> (*) One problem of saying this though is that in some cases we're
> effectively saying to app devs that either they remove features from
> their Windows version (like Marble does) or just don't have them in
> the first place on Linux, neither of which is terribly appealing.
> 
> > On Windows, users want to have a standalone installer for each
> > application.
> 
> Do they, or is that just what they are used to?  Mac users seem to
> have very quickly adapted to the idea of a store instead of hunting
> down individual downloads, as have every single Android and iOS user.
> Will Windows users be that different?  And I still remember the old
> days when I had to go looking for DirectX or VC or .NET packages to
> install first.
> 
> > I think part of the misunderstanding is that the average Windows user
> > (which we'd like to target) doesn't want to install the whole KDE
> > experience on his desktop.
> 
> That I definitely agree with, Windows users do want particular apps
> only, and having just 3 or 4 key apps installed is the scenario we
> should seek to support.  We may not want to support installing every
> possible KDE utility or widget.  However we are a community and need
> to look at how all of KDE could benefit from successful apps on
> Windows.  Is there really any point in our having one killer app on
> Windows that everyone installs, but then ignore everything else we
> have on offer?  How do we make it easy for people who try Krita and
> are impressed to try other KDE apps?
> 
> We also need to think about the modules, how would we package Edu or
> Games?  A separate installer for each edu app or game, no matter how
> trivial?  Or would a teacher or parent want a single installer they
> could choose apps from?  Or perhaps install them all and have a single
> launcher interface?
> 
> > But seriously, that's cheap nowadays
> 
> Not for everyone.
> 
> > Windows users are used to big binary blobs. (Just reminds me of HP's
> > printer driver installers, which are roughly about 200 MB...)
> 
> Which *everyone* complains about and only download because they *have*
> to.  We're not in the position of an HP or Adobe, we should try to
> make the marginal cost of installing more KDE apps as small as
> possible.

Agreed. It's not good practice. But it's not like we ship 200 MB of bloatware 
like they do. We ship libraries which are required to make the application 
run.
 
> Look, there's good arguments either way, and I'm really not in a
> position to say what's right, but I'm looking at it from the
> perspective of getting as many KDE apps on as many platforms as
> possible.  If I wrote an app and faced having to learn 5 different
> packaging methods and 5 different distribution methods then I might
> not bother.  We need to make it easier.

Sure. But if you seriously want to target 5 different platforms, you *have* to 
spent some time on polishing your app on each of them. And that also means 
polishing and testing your package on each platform. You can't just make it 
compile on that platform and hope everything will just work.
Of course, we should provide tools which make this is as easy as possible.

> John.

Let me sum up my ideas:

- I definitely want single-app *standalone* application installers on Windows
  (These are undoubtedly useful to show off what we have in KDE
  even for unexperienced computer users)

- Make these installers as robust as possible
  (i.e. by *not* downloading dependencies, as this will likely
  cause more headaches when debugging what's going wrong)

- Make it standalone. MS Windows mostly stays backwards compatible,
  hence these installers could stay intact for a wider audience
  for a long time
  (just take a look at packages such as gnuwin32 [1],
  which are dead old but still work)

- The KDEwin installer should definitely stay, for power users,
  such as for teachers wanting to install the complete Edu suite or similar,
  just like John mentioned.

Just my two cents,

Greets

[1] http://sourceforge.net/projects/getgnuwin32/

-- 
Kevin Funk


More information about the Kde-windows mailing list