2012/10/27 Joost Andrae <joost.and...@gmx.de> > Hi Marcus, > > Am 26.10.2012 23:06, schrieb Marcus (OOo): > > I've modified the subject as I think this topic deserves its own, new >> thread. >> >> > that is a good idea. > > > Am 10/26/2012 07:28 PM, schrieb Ariel Constenla-Haile: >> >>> On Wed, Oct 24, 2012 at 05:27:41PM +0200, Jürgen Schmidt wrote: >>> >>> Once thing to pay attention for the next release is the increasing size: >>> more than 14 Gb for Linux packages only. This is going to be even more, >>> as more languages are added. INFRA has already complained after the >>> first release (can't find the message right now) about the size of our >>> dist/ folder, so we must think about a solution, before they complain >>> once the next release is uploaded. >>> >> >> IMHO you can think and try whatever you want. At the end there is only >> one solution: >> >> Cleanup the packaging, delete redundat files, rearrange how the install >> files will be packed, think new how the installation on the users-side >> could be done. >> >> > 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... - ... While a new packaging system is an interesting idea, we need to be *really* careful to not left many users outside it. Regards Ricardo
