[DISCUSS] Cleanup installation files, make them more modular

["Marcus (OOo)" <ma...@wtnet.de>]

I've modified the subject as I think this topic deserves its own, new 
thread.

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.

Example:
For every platform, we have exactly the same files in every full 
install, except for the language resource files. So, when we can make it 
that only the core (languages-independent) files are once on the mirrors 
and then the language resource files besides, then it would be possible 
to do the installation process completely new - with the following rough 
steps:

1. Create a new basis installer: little, tiny and already localized.
2. The user can choose what he wants: applications, languages, 
templates, extensions.
3. The basis installer downloads this file set from the mirrors.
4. It does the installation on the PC.
5. Finally AOO is ready to use.

And as goody maybe it's possible to create an install file, so that the 
user can re-install his AOO version whenever he wants, without to 
download everything again from the mirrors.

Marcus

Re: [DISCUSS] Cleanup installation files, make them more modular

[Joost Andrae <Jo...@gmx.de>]

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

Re: [DISCUSS] Cleanup installation files, make them more modular

[RGB ES <rg...@gmail.com>]

2012/10/27 Joost Andrae <Jo...@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

Re: [DISCUSS] Cleanup installation files, make them more modular

[Joost Andrae <Jo...@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

Re: [DISCUSS] Cleanup installation files, make them more modular

["Marcus (OOo)" <ma...@wtnet.de>]

Am 10/27/2012 12:58 AM, schrieb Ariel Constenla-Haile:
> On Sat, Oct 27, 2012 at 12:47:56AM +0200, Marcus (OOo) wrote:
>> I don't see the context to bad inet connections. Maybe you can tell
>> with some other words?
>>
>> When we do the restructure then we will have less content on the
>> mirrors. But for the user there is no change as they still have to
>> download all files that are necessary to do the installation; maybe
>> less when they explicitely disables some applications and content
>> that are currently be installed by default.
>
> If I understood this approach, the tiny installer downloads all the rest
> at install time, that means you need a good internet connection at
> install time.

Not really, the installer can first download everything that is 
necessary and then start the installation. It should be technically also 
possible to continue a download where it stopped due to an interrupted 
inet connection.

So, at the end it's up to us how to design the tiny installer.

Marcus

Re: [DISCUSS] Cleanup installation files, make them more modular

[Ariel Constenla-Haile <ar...@apache.org>]

On Sat, Oct 27, 2012 at 12:47:56AM +0200, Marcus (OOo) wrote:
> I don't see the context to bad inet connections. Maybe you can tell
> with some other words?
> 
> When we do the restructure then we will have less content on the
> mirrors. But for the user there is no change as they still have to
> download all files that are necessary to do the installation; maybe
> less when they explicitely disables some applications and content
> that are currently be installed by default.

If I understood this approach, the tiny installer downloads all the rest
at install time, that means you need a good internet connection at
install time.


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina

Re: [DISCUSS] Cleanup installation files, make them more modular

["Marcus (OOo)" <ma...@wtnet.de>]

Am 10/27/2012 12:33 AM, schrieb Ariel Constenla-Haile:
> On Fri, Oct 26, 2012 at 11:06:45PM +0200, Marcus (OOo) wrote:
>> I've modified the subject as I think this topic deserves its own,
>> new thread.
>>
>> 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.
>>
>> Example:
>> For every platform, we have exactly the same files in every full
>> install, except for the language resource files. So, when we can
>> make it that only the core (languages-independent) files are once on
>> the mirrors and then the language resource files besides, then it
>> would be possible to do the installation process completely new -
>> with the following rough steps:
>>
>> 1. Create a new basis installer: little, tiny and already localized.
>> 2. The user can choose what he wants: applications, languages,
>> templates, extensions.
>> 3. The basis installer downloads this file set from the mirrors.
>
> I've read this approach the other times this was discussed. While this
> might be the current mainstream market trend, handy for those who send
> their e-mails from their i-Phones and their i-Pads, it won't be suitable
> for users from less-developed countries with bad internet connection.
>
> Does OpenOffice user base come from this kind of countries? These
> numbers don't seem to tell so:
> http://www.openoffice.org/stats/countries.html But I've also read "why
> would someone use OpenOffice if he/she can pay for MS Office?", meaning
> that OpenOffice user base is made of people who can't afford MS Office,
> we could also asume they can't afford a good internet connection, even
> on developed countries like the top 7 in the list (this argument missed
> the point than someone may want to use OpenOffice just because it's free
> software, even if can pay for MS Office - or get an ilegal copy).

I don't see the context to bad inet connections. Maybe you can tell with 
some other words?

When we do the restructure then we will have less content on the 
mirrors. But for the user there is no change as they still have to 
download all files that are necessary to do the installation; maybe less 
when they explicitely disables some applications and content that are 
currently be installed by default.

Marcus

Re: [DISCUSS] Cleanup installation files, make them more modular

[Ariel Constenla-Haile <ar...@apache.org>]

On Fri, Oct 26, 2012 at 11:06:45PM +0200, Marcus (OOo) wrote:
> I've modified the subject as I think this topic deserves its own,
> new thread.
> 
> 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.
> 
> Example:
> For every platform, we have exactly the same files in every full
> install, except for the language resource files. So, when we can
> make it that only the core (languages-independent) files are once on
> the mirrors and then the language resource files besides, then it
> would be possible to do the installation process completely new -
> with the following rough steps:
> 
> 1. Create a new basis installer: little, tiny and already localized.
> 2. The user can choose what he wants: applications, languages,
> templates, extensions.
> 3. The basis installer downloads this file set from the mirrors.

I've read this approach the other times this was discussed. While this
might be the current mainstream market trend, handy for those who send
their e-mails from their i-Phones and their i-Pads, it won't be suitable
for users from less-developed countries with bad internet connection.

Does OpenOffice user base come from this kind of countries? These
numbers don't seem to tell so:
http://www.openoffice.org/stats/countries.html But I've also read "why
would someone use OpenOffice if he/she can pay for MS Office?", meaning
that OpenOffice user base is made of people who can't afford MS Office,
we could also asume they can't afford a good internet connection, even
on developed countries like the top 7 in the list (this argument missed
the point than someone may want to use OpenOffice just because it's free
software, even if can pay for MS Office - or get an ilegal copy).


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina