Re: [MinGW-dvlpr] Package archive formats and compression

[Earnie B. <ea...@us...>]

Quoting "Aaron W. LaFramboise" <aar...@aa...>:

> Unfortunately I need to re-open this discussion.  As some people have
> noticed, I posted the GCC snapshot in 7-ZIP format as well as gzip.
>
> The problem is that, even with symbol stripping etc, the GCC binaries
> are just getting really big.  I didn't realize how bad this was until
> now.  Also, several driver programs expect to be filesystem links,
> resulting in duplicated storage which greatly increases the size of the
> binary.
>
> With tar.gz and without any sort symbolic links or hard links, the file
> is just massive.  I used 7-ZIP as a short-term solution, because I knew
> it would give good savings, but we need to think this out for the long term.
>
> So there's two issues:
>
> 1) Address lack of symbolic links and hard links
>

This can only be accomplished with our own versions of our favorite 
file system functions.  But this would move us out of the realm of 
Minimalist.  Perhaps what we need is a modified version of tar that can 
create the copies from the symlink info stored in the file.  I have no 
problem stating that you must use MinGW supported tools to unarchive 
the files we distribute.

> Avoiding duplicated driver executables etc will save tons of space and
> decompression time
>
> 2) We need better compression than .gz
>

As I stated earlier I prefer bzip2 for that reason.  The compression is 
better.  7zip is even better.  The smaller the distributed file the 
better we will be at serving ourselves and our users.

3) Use shared libraries.

We have avoided shared libraries because others would need to 
distribute them with their software.  But I think we need to re-think 
our decisions for that.

> Besides 7-ZIP, rzip or lrzip may be particularly effective here,
> although I have not tried them.  I'm not actually sure if they have
> decent win32 ports, though.  bzip2 probably will not give good enough
> savings.  I believe baseline portable .ZIP is roughly equivalent to .gz.
>

Uhm, no ZIP is worse than GZIP.

> No matter what we do, we probably should still continue to offer a
> baseline distribution in .gz.
>
>
> What do you guys think?
>

I think the topic is worth discussing but I don't see a good answer 
unless we are willing to host the unarchiving software; which should be 
no problem, of course.  But I think we need to agree on that first and 
then follow up with the packaging using the agreed upon hosted 
software.  7Zip has a windows GUI and has been ported to Linux so I 
think it should suffice to cover our needs.  However we need to be able 
to build it natively with MinGW's GCC.

Earnie