Colin, Pádraig,Thanks you for your input. At the moment it seems like the runtime degradation is imperceptible (I ran some large-scale tests). However, if you would like me to, I can fix the potential slowdown and send a patch that uses hash lookup instead. It's a more general solution; refusing entries to mask this slowness only postpones the inevitable.
Regarding popularity, I would not look at Debian popcon alone. In my subjective opinion it's not much more unpopular than lrzip; popcon is Debian-only and opt-in only, I think that the statistics it shows skew against new (fsvo new -- 2022 was 4 years ago) tools. bzip3 is also packaged in Fedora, Arch, Alpine, Homebrew, FreeBSD ports and others. I am not sure however if we can get data out of these. However, nonetheless, per popcon I saw that all of { rzip, zoo, unalz } rank similarly or worse to bzip3 and still have an entry on the list.
> I also find the naming strange when it is unrelated to bzip2. Not > that it is a reason to block the addition, of course.It is a common objection. It makes sense. Sadly, it is also the trodden path of software naming: lrzip (Colivas) came as an independent improvement after rzip (Tridgell); Seward's original bzip had nothing to do with Katz' regular ZIP by any stretch; bzip2 shares no code with bzip. bzip3 can be thought as a synthesis of these both with some nifty new software engineering practices. Names are meaningless just like that. I use tar daily, but I have never held tape storage in my hands.
-- With Valediction, Kamila Szewczyk (https://iczelia.net)
OpenPGP_0xC868F0B6DE38409D.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
