incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From RGB ES <rgb.m...@gmail.com>
Subject Re: [DISCUSS] Cleanup installation files, make them more modular
Date Sat, 27 Oct 2012 13:09:52 GMT
2012/10/27 Joost Andrae <Joost.Andrae@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message