Hi,
I have some items to add:
- The installer packages should be modulized to allow the selection of
parts (already done but we shouldn't forget to work on this)
- Localizations should be separated from the binaries (soffice.bin, libs,
resfiles). Maybe it's a good idea to separate language packs from the
installer and that localizations are not part of the base installation
package (this can solve parts of the INFRA issues)
- The installer structure should allow small updatable packages (we
already had this for MSI, MSP files). We should think about designing a
more heterogenous approach for introducing a patch based update process.
- Documentation might be divided into parts that link to the soffice
instance (via HelpIDs) and into parts that allow intermediate updates
without interfering with the application logic. This would allow a
continous development process for those who like to work on documentation
items.
Just my 2 Euro Cents...
Joost
Last week there was an user on the ES forums with a particular problem: he
was trying to install AOO in a school on a really old machine without
network connection (no internet, no internal net, nothing) that runs Linux
and needed to donwload (and burn into a CD) the right AOO version on a
Windows machine. How such theoretical installer will manage those
situations? Yes, this particular user is a "corner case" but it is quite
easy to think about *many* corner cases... for example:
- Such installer should be multi platform, something like a java based app,
BUT can we presume that all systems have a java virtual machine working?
While this is usually true on Linux, it is not so true on Windows or Mac.
- How such installer will integrate with package managers on Linux? This is
a problem not only with rpm and deb, the currently supported packages, but
also with sabayon's entropy, with pardus' PiSi system...
yes, the Linux package management is a nightmare and the only way to
work-around this is to provide packages that don't make use of it...
Joking aside, using system packages is needed to be available for
distribution applications that manage the rollout within a network (LAN,
WAN). And I belive there is already some kind of patch management on
Linux, Solaris, FreeBSD and on MacOS available that is comparable to the
MSP approach on Windows based systems. Unfortunately on Linux we have
several packaging systems (.deb, rpm, etc.) that we need to take care
of. On Linux there's another thing that needs attention that's the
desktop system integration which differs from distribution to
distribution and it's really a nightmare because some distros provide
diverse frameworks like Gnome, KDE, etc. that need their own
integration. This could be one thing that could be out-sourced into
extra packages that a Linux user can download for his/her distribution
additionally to the base installation package.
Kind regards, Joost
