Created attachment 202207 [details] Switch to tar:lzma The difference in size between binutils-2.32.tar.bz2 and binutils-2.32.tar.xz is about 30% and the .tar.lz is slightly smaller still. It may or not be worth changing now -- when all the mirrors already have the .tar.bz2 variant -- but it should certainly be done with the next upgrade of the port.
Maintainer feedback, please!
Binutils uses tar.xz archive as of r518918 so I think we can close this now?
The currently-latest release 2.34 is available in .lz and .xz variants, the former still about 5% smaller than the latter. I don't understand, why download anything other than the _smallest_ archive...
Mainly because tar.xz is a very common format so availability is good and to avoid the controversy about lz(ip) format.
(In reply to daniel.engberg.lists from comment #4) > Mainly because tar.xz is a very common format so availability is good Availability of binutils in tar.lz is just as good -- my question was not general, but about binutils only... > and to avoid the controversy about lz(ip) format. I must be out of the loop... What controversy?
https://web.archive.org/web/20191017162427/https://blogs.gentoo.org/mgorny/2014/02/22/a-few-words-on-lzip-compressor/ Sums it up pretty much While we have full(?) support I don't see any good in supporting the format the way it's being promoted and tar.xz us widely adopted and well tested by now seeing it being used pretty much everywhere. FWIW, Debian rejected the patch to use it for packages compared to xz along with the reasoning why, link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=556960
Wow, what a drama I missed... > I don't see any good in supporting the format the way it's being promoted I don't think, this consideration is valid -- and the argument admissible. What's next? Checking the background of FreeBSD developers? Spiting unpleasant people by refusing to use software they've developed? Seriously?.. Given the necessary decompression support already being in FreeBSD, the _only_ valid argument remaining is the file size... However an archiver is being promoted, the only objective metrics is the size of the resulting archive.
I'm not saying any of reasons above were taken into account however the fact that tar.xz is much more tested (used) than tar.lz is still a valid point. If you still think tar.lz should be used it's up to the maintainer, we're talking about a very minor change in size compared to previously used tar.bz2 archive which isn't generated for 2.34.
I don't see any reason to ignore it, I will switch to it when updating to binutils 2.34 thank you for the notice, and sorry this bug has been open for more than a year, I somehow failed to notice it...
I think we can close this now since there's a new maintainer who kept using tar.xz ?
(In reply to Daniel Engberg from comment #10) > I think we can close this now since there's a new maintainer who kept using > tar.xz? As long as .tar.lz distfile is still smaller, I don't see why shall we close a valid PR. Michał's "controversy" post header says it is outdated and no longer adequately expresses his attitude towards the two competing formats. Also, the picture is incomplete without giving a word to the opposite side: https://www.nongnu.org/lzip/xz_inadequate.html. Debian's (momentarily) decision not to use lzip for compressing *their own packages* is irrelevant to this discussion. I personally had better experience with .tar.lz and always prefer it; our framework supports it natively as a first class citizen (USES+=tar:lz) so whenever it gives smaller distfiles, we should switch to it upon next update.
Over to current maintainer, up to him to decide he this should be closed or not.
The switch had occurred with ports 32d885a48f08, closing.