16.02.2017, 02:12, "Mathias Hasselmann" <[email protected]>: > Am 15.02.2017 um 13:05 schrieb Dmitry Shachnev: >> On Wed, Feb 15, 2017 at 12:28:11PM +0100, Kevin Kofler wrote: >>> I would kindly request you to at least use tar.xz (rather than tar.gz) for >>> the tarballs. (What you use as the Windows format is something you need to >>> sort out with the Windows people.) The fact that tar.gz is still the most >>> downloaded is probably mostly out of habit, or maybe your download site is >>> directing to them by default (which ought to be fixed anyway, even if you >>> were to keep both). tar.gz has no advantage over tar.xz, it is just a lot >>> larger. Switching to the tar.gz tarballs (from the tar.xz tarballs that are >>> currently used) would increase the size of distributions' source packages >>> (source RPM etc.) significantly. > > If distros care about size they can re-compress. > Well, and to my experience they do. > >>> It is sad that the legacy gzip compression is living a renaissance due to >>> automatic tarball exports from GitHub and the like producing only that >>> format. It should finally be retired now that there are algorithms that are >>> just as open and that compress significantly better. At least for projects >>> like Qt that produce their own tarballs and are already able to produce xz- >>> compressed ones, I see no reason whatsoever to switch back to the obsolete >>> gzip. >> >> +1, please leave tar.xz instead of tar.gz. >> >> Users of all modern UNIX-like systems are able to decompress tar.xz, so .gz >> has really no advantage over .xz. > > That's a somewhat limited point of view. Yes, xz archives are slightly > smaller, but to be honest: In the days of 4K video streaming saving > 100MiB of download size doesn't seem as important as it was. > > The actual value of gzip and the reason for its return seems to be its > significantly lower CPU usage. This is useful to reduce server load on > heavily utilized services like github. This is useful to reduce > development roundtrip cycles.
I think nobody here would challenge this statement. But it has nothing to do with src archives that are compressed once and decompressed thousands of times. > > Just to illustrate this I've collected some numbers on my Thinkpad: > > Command | Average | Savings | Archive | Savings > | CPU time | p. build | size | @100MBit > ==================================================== > gzip | 00:44.19 | 09:54.58 | 469 MiB | 00:00.00 > gzip -9 | 01:55.58 | 08:43.18 | 465 MiB | 00:00.32 > xz | 08:46.16 | 01:52.60 | 354 MiB | 00:09.20 > xz -9 | 10:38.77 | 00:00.00 | 333 MiB | 00:10.88 You should use pxz instead of xz for fair results. > > Is it worth to spend 10 additional minutes per CI cycle just to save our > users a very few seconds of download time? > > Looking at the problems behind providing an official 5.8.1. Looking at > my personal experience with slow CI systems I clearly vote for speeding > up the Q/A process and sticking with .zip and .tar.gz. > > Besides: Does it really make sense to fully test the expensive .xz and > .7z builds? In my opinion it would be fully sufficient to only give the > inexpensive .zip and .gz archives full test coverage. At least the .xz > could be generated on the fly after uploading to the web server by > simply decompression: > > gunzip < qt-sources.tar.gz | xz -9 > qt-sources.tar.xz > > Ciao, > Mathias > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
