GNOME Bugzilla – Bug 566001
Windows installer package too big, should be more on-demand and smaller
Last modified: 2018-06-29 22:15:04 UTC
At 60.6 MB, the Windows installer is pretty big for what Gnucash does. There seem to be some areas that contribute bytes out of proportion to their usefulness. 1. Help files. share/gnucash/help takes up 17.8 MB compressed. Also, full help files are included for two languages: English and Italian. Many users do fine with online help, and most of those who want local help will only speak 0-1 of these languages. 2. Localization files. 103 localizations are included, taking up 14.3 MB compressed. Surely most users only want 1-4 of these languages. Not all languages are the same size, but even the biggest only takes up 336 KB compressed. 3. AQBanking. Maybe this is a can of worms, but it sure brings in a lot of QT libraries. Banking setup is currently very buggy in the Windows build (see 565496 and others). Features shouldn't be removed willy-nilly for the sake of size, but they've got to work first! These three areas account for 30-40 MB of a 74.8 MB ZIP file depending on whether you count AQBanking. Even allowing that the help files will compress a bit better in the setup archive, this should still slim down the installer package by maybe 30%. Best practice is to offer the language versions separately to cut down on download size. Microsoft, Adobe, most companies with large software downloads do this. (And, heck, Lightroom only takes up 71 MB, which isn't much larger than Gnucash ...) Alternatively, some open-source products will offer a Sourceforge download of just the core program, plus separate localization + help packages.
Full Ack. A few other thoughts that come to my mind: * Cross-compile gnucash: I think this should be possible. OTOH, the compiled files must be fed into Inno and I would like to see that automated from a build machine eventually as well. Inno does not seem to support this -> +1 for NSIS. - Maybe GnuCash can be built from jhbuild... http://live.gnome.org/Cross compiling GTK%2B for Win32... later * Share files with installed versions of GTK+ (Gimp), Goffice (Gnumeric). This may not necessarily be easier with NSIS, but at least both these programs use NSIS. * Separating gtk+, goffice, help files, language files, aqbanking and perl/fq is probably a good idea, maybe, as you said, via downloads from the installer. Maybe we should coordinate with other gnome OSS/Win32 here as well. In a later step we can also agree to build ready-to-use installers for certain setups, like a -full, -de, -it, -hbci or whatever version. I will try to contact the Gnumeric and GTK+ win32 developers. Christian, do you remember why we chose inno over nsis?
> Christian, do you remember why we chose inno over nsis? Because I already knew inno even for the non-trivial tasks of file creation etc., but I didn't know nsis. > Separating gtk+, goffice, help files, language files, aqbanking and perl/fq > is probably a good idea, maybe, as you said, via downloads from the installer. What we need is a package manager with some online repository. KDE has built something like this for themselves (I forgot the name). Cygwin has it, too.
I already did some work in this direction... But I'm used to work with the preprocessor -- don't know if this will be a problem for you. I will attach my current file for review. It's not finished, but you'll see, that the build script has to be modified to support this type of install. I will get back with a complete solution, but that will take some days.
Created attachment 135513 [details] Inno setup file not ready for use! Only meant as an example
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=566001. Please continue processing the bug there and please update any external references or bookmarks.