Maybe we should wait until lzip is widely available before adopting it? Meanwhile, bzip2 is already widely adopted, and is smaller than gzip. Debbie
On Sep 7, 2016, at 12:46 AM, 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.
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.
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.