<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014-04-02 19:24 GMT+02:00 Jaroslav Reznik <span dir="ltr"><<a href="mailto:jreznik@redhat.com" target="_blank">jreznik@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
= Proposed System Wide Change: lbzip2 as default bzip2 implementation =<br>
<a href="https://fedoraproject.org/wiki/Changes/lbzip2" target="_blank">https://fedoraproject.org/wiki/Changes/lbzip2</a><br></blockquote><div><br></div><div>While the speedup is desirable, it's not really obvious that this is the right time to do the change.<br>
<br></div><div>Looking at <a href="http://lbzip2.org/news" target="_blank">http://lbzip2.org/news</a> , lbzip2 is still fixing crashes during compression and decompression. That's rather troubling: we need the bzip2 implementation to be roughly as stable as file system<i>.</i> The Change page implies that bzip2 is not actively maintained; that may be true but looking at <a href="http://bugzilla.redhat.com" target="_blank">bugzilla.redhat.com</a>, there has AFAICT never been a bug reporting that something can't be compressed or decompressed—that's a <i>very</i> high bar to match. (I do appreciate that assertion failure and silent miscompression are not the same thing.)<br>
</div><div> <br></div><div>Having the library implementation and the command-line implementation completely separate may frustrate debugging efforts when using an application-builtin compression and saving uncompressed and compressing manually may give different results. That's not a deal-breaker but having a single implementation would certainly simplify things.<br>
<br></div><div>Ultimately the easiest way to make this implementation change happen, not only in Fedora but in all distributions, would be for the improvements to be integrated into the upstream bzip2 codebase; has that possibility been explored at all?<br>
</div><div> Mirek<br></div></div><br></div></div>