Did you really unzipped all f* files or did you tried only gzip with -9?
... This is only for clearness ...

Could you evaluate the time needed to decompress files with better
compression? How much is it longer?

The former. I applied 'unzip'ed all files beginning with f0_ and f_
individually and then 'zip -9'ed again, then copied other ordinal
files to the same working directory and run 'gnutar -zcf' to make the
reduced .tar.gz.

How much is it longer? That's a good question. I will try it.

Hi Tora,
welcome back to OpenOffice.
of - svesik: Is this something for you?

  I got unexpected results that showed the original files took longer
than the 'zip -9' files during extraction. The results cannot be
accepted unless the same algorithm of compression is used. 

Results:
  zip -9   : 13.75 seconds
  original : 14.46 seconds

  The test machine I used has zip version 5.32 delivered on 3 November
1997, while scpzip in scptools/source/linker seems to use the latest
version, zlib/download/zlib-1.1.4.tar.gz . So, it can be inferred that
the unzip make the best performance when the files are prepared with
the same version's zip. But I actually have no evidence.

Environment:
  Solaris 9 SPARC
  Sun Blade 150
  UnZip 5.32 of 3 November 1997, by Info-ZIP.

Target file:
  OOo_1.1rc5_SolarisSparc_install.tar.gz

Instructions:
 1. Prepare a working directory.
    w=/tmp/work
    mkdir $w

 2. Apply 'unzip' command to the 'zip -9'ed files.
    cd OOO_1.1.0_SOLARISSPARC_INSTALL
    (for x in f* ; do time unzip -d $w $x ; rm -r $w/* ; done ) >&
../zip-9-trial-1.log
    Did the same trial three times repeatedly.

 3. Apply 'unzip' command to the 'zip -5'ed files.
    cd ../OOo_1.1.0_SolarisSparc_install
    (... the same above ...) >& ../zip-5-trial-1.log
    Did the same trial three times repeatedly.

 4. Now that the log files contain a spending time. e.g.:
    real    0m0.389s
    user    0m0.250s
    sys     0m0.110s

    Count up the time that 'user' spent.
    perl -ne 'if (m/\Auser\s+([0-9]+)m([0-9.]+)s/) {$t+=$2}; END
{print "$t\n"}' zip-9-trial-1.log

    Calucurate the average times.

Could you evaluate it in another way, if you have a chance?

accepting, setting status to 'started' 

decreased size for downloads, even at the expense of slight increase
in installation time would be worthwhile

Here are other results of evaluating the extraction time in second and
the size of ".tar.gz"ed file. In this test unzip/zip commands that had
come with Solars 9 were used.

             Average 1st     2nd     3rd     Size     Ratio
 "zip -1"ed: 23.943 (23.168, 24.347, 24.314) 96249132 (1.0689)
 "zip -5"ed: 22.415 (22.266, 22.533, 22.447) 90178013 (1.0015)
 "zip -9"ed: 24.378 (24.076, 24.910, 24.147) 88657755 (0.9846)
 original  : 25.478 (26.934, 25.384, 24.116) 90046203 (1.0000)
 
  In conclusion, "zip -5" is fastest for extraction; "zip -9" spends
more time, but its size becomes smallest. If the versions of
compression and decompression differ, it takes much longer. Do you
have any reports or papers that support these results?

  Revised way I used in order to avoid unexpected stop:
  (for x in f* ; do rm -rf $w/* ; time unzip -o -d $w $x ; done )

I would suggest also trying 7-zip (http://www.7-zip.org/) as it generally
compresses zip files slightly better than infozip/winzip (if you use the maximum
options). 7-zip is open source with GUI + command line versions (win32 only though).
I don't think that decompression time should be a concern at all, especially if
we are talking about the distribution archives.
I have no idea (as an end user) how to recompress all the f* files other than
manually, so I can't really test this. Unzipping & recompressing with 7-zip
"OOo_1.1.0_Win32Intel_install.zip" saved about 9k but that's nothing to judge by
(because almost all the files in it are already compressed you are lucky to get
much compression at all).

Do we still  have control over compression ratio for our installer?

Reset assignee on issues not touched by assignee in more than 2000 days.