On 7 September 2016 at 08:46, Paul Eggert <eggert@cs.ucla.edu> wrote:
Jon Skeet wrote:
So whose preference *is* lzip?
Mine, mostly. Antonio Diaz Diaz also expressed a preference for it. Admittedly he's biased, as he is an lzip maintainer. (I'm biased too, as I'm a gzip maintainer....)
I don't see that that's any argument for changing now.
The point is that after we changed to gzip format, things turned out all right. This sort of change is not as much work as one might fear.
Perhaps the situation is not the same as it was before, though? Perhaps the data is being used in different contexts?
One option ...: distribute multiple formats.
You mean .gz, .lz, .bz2, .zip, etc.? That sounds like it'd be a bit more work for me, for the staff, and for newcomers trying to navigate through the distribution.
It sounds like it *should* be a matter of adding a few lines per distribution format to whatever scripts are being used. Helping newcomers should be reasonably straightforward with documentation: "We have two kinds of distribution packages: one has separate code and data (point to the existing gzip files), and one includes (describe new contents here). The latter package is available in zip, gzip and lz formats." There are plenty of other packages which allow a choice of compression format - for example, look at the Apache distribution site ( https://httpd.apache.org/download.cgi) which allows the source download as tar.gz or tar.bz2. I do acknowledge that it would be more work, but I suspect it would be less work than the time we've all taken to write all these emails so far, and it should be a one-time job... it shouldn't involve any more *ongoing* maintenance. If you like, though, you can take on part of that job, and it might be
helpful to do do so as this is a good time to experiment with distribution formats anyway. You could maintain a downstream server, say, one that delivers other distribution formats. Right now in the experimental GitHub version, for example, 'make tarballs' generates a file tzdb-2016f-41-g6d70eda.tar.lz, corresponding to the 41st Git commit after 2016f, with abbreviated hash 6d70eda. So, your web server could convert that to (say) bzip2 compression format, and redistribute a file named tzdb-2016f-41-g6d70eda.tar.bz2. That might be a nice thing to have.
While that would be easy enough to do, I think there's benefit in having the files hosted on IANA as a single trusted source. (Then there's tzdist of course, but that's a whole other matter...) Jon