Re: [MinGW-dvlpr] Package distribution format Was: New runtime and w32api

[Keith M. <kei...@us...>]

On Monday 01 September 2008 16:07:12 techtonik wrote:
> we could instead simply call it:--
>
> >  runtime-3.15-mingw32-dev.tar.gz
> >
> > Is that too radical a change to adopt?  Opinions?
>
> IMHO (from a user perspective) such packages (as ordinary files
> among other files) have only three distinctive features that
> matter: 1. relation to mingw (i know where it belongs)
> 2. product name (to distinguish between components)
> 3. version
>
> Everything else is specific to development process and could be
> described in documentation either inside or online.

Also from the perspective of the user, I consider it advantageous to 
be able to see at a glance, from the package name, whether or not the 
package represents a stable release, or otherwise.  If you only 
mention within the package, that it is a snapshot, in an alpha or 
beta phase of development, the the users have to download the package 
to ascertain that.  If you rely on external online documentation, 
then in the first instance, the package maintainer has the additional 
burden of maintaining that, and in the second, the user has to go 
looking for it.  If you reflect the development status within the 
package name itself, then everybody wins.

> So, I would name files as mingw-runtime-3.15-dev.tar.gz

And now I have no way, other than by guesswork, to know whether this 
package relates to mingw32 or to mingw64, without again seeking out 
additional documentation.

A further consideration, which we also discussed previously, was that 
incorporation of such meta data directly within the package name 
could also be advantageous in accommodating an *automated* system for 
cataloguing and categorising packages.

> Using the opportunity to discuss package names - may I ask why not
> to switch from tar.gz to tar.bz2 bundles? It is not an issue for
> NSIS to unpack these,

With the advent of mingw-get, it needn't be an issue anyway; we can 
develop that to accommodate whatever compression best suits our 
requirements, and there may be significant peripheral benefit in 
deprecating support for arbitrary delivery mechanisms which are 
beyond our ultimate control.

> bz2 is supported long ago in various OS and 
> it provides smaller downloads. Using current set of installer
> files:
>
> binutils-2.17.50-20060824-1.tar.gz
> gcc-core-3.4.5-20060117-1.tar.gz
> mingw-runtime-3.14.tar.gz
> w32api-3.11.tar.gz
>
> Switching to .bz2 provides (14919910-12029729)/14919910 ~ 20% of
> space/traffic/bandwidth economy.

This isn't a new notion.  When we discussed it before, IIRC we came to 
the conclusion that we might just as well adopt LZMA compression; it 
beats BZ2 into a cocked hat, in most cases[*].  However, the current 
issue is the adoption of a consistent convention for the naming of 
packages, and there is no reason why that convention should not 
accommodate differing compression formats.

Regards,
Keith.

[*] Although BZ2 is commonly better than GZ, I have seen examples 
where GZ can be up to 20% better than BZ2, (I believe the execwrap 
package is one such).  Aaron did some testing, when we discussed this 
previously, which showed a significant advantage for LZMA, in every 
case he evaluated.