incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joost Andrae <>
Subject Re: [DISCUSS] Cleanup installation files, make them more modular
Date Sat, 27 Oct 2012 13:54:43 GMT

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

View raw message