F21 System Wide Change: lbzip2 as default bzip2 implementation

Al Dunsmuir al.dunsmuir at sympatico.ca
Wed Apr 2 22:24:01 UTC 2014

On Wednesday, April 2, 2014, 2:03:38 PM, Bill Nottingham wrote:
> Jaroslav Reznik (jreznik at redhat.com) said:
>> = Proposed System Wide Change:  lbzip2 as default bzip2 implementation =
>> https://fedoraproject.org/wiki/Changes/lbzip2
>> Change owner(s): Mikolaj Izdebski <mizdebsk at redhat.com>
>> This change aims at making lbzip2 [1] default bzip2 implementation used in 
>> Fedora. 
>> == Detailed Description ==
>> lbzip2 is an independent implementation of bzip2 compression tool. It provides 
>> interface strictly compatible with bzip2, but also adds several new features 
>> and improvements, such as:
>> * multi-threaded operation for both compression and decompression, with almost 
>> linear scalability,
>> * improved performance, even on single-core systems,
>> * improved extra utilities (bzdiff, bzless, bzip2recover, etc.),
>> * improved compatibility with gzip. 
>> lbzip2 is a mature project and it has been used in production for years. It is 
>> already packaged for Fedora and it is also available in EPEL.

> A quick check shows lbzip2 doesn't provide a library interface, much less
> one compatible with libbz2. Is that ever intended?

> If it's not, saying lbzip2 is the default bzip2 *implementation* may be a
> bit of a stretch. Perhaps s/implementation/command/.


This  clarification is significant.  The change proposal text needs to
be updated to reflect this.

As long as the encoding is guaranteed to be byte-for-byte identical to
that produced by the original bzip2 (and libbz2) implementation, the
risks are lowered.

Scenarios   affected  by  this  substitution  are  those  with  direct
invocation of the command (from the command prompt, a shell script, or
system() type call).

The  lbzip2 utility sounds interesting, and I am now disappointed that
there is no separate library interface with these characteristics that
we  can  investigate using instead of libbz2. As later comments state,
perhaps in the future.


More information about the devel mailing list