F21 System Wide Change: lbzip2 as default bzip2 implementation

[Chris Adams]

Once upon a time, drago01 <drago01 at gmail.com> said:
> Well the change says " multi-threaded operation for both compression
> and decompression, with almost linear scalability" linear scalability
> means speed ups on the range of 2-8x on current desktop / laptop
> systems.
> Which I'd call a "significant gain" ;)

That depends.  If I made an alternate "mv" that ran 10 times faster,
would we go through the pain of alternatives to offer two options for
it?

How much impact on real-world system usage will speeding up the bzip2
command offer?  Many of the common users (such as rpm) are linked
against the library and don't use the command, so they won't be
impacted.  We'll end up with more disk space used, because the current
/usr/bin/bzip2 and friends are linked against the library (so there's
only one copy of bzip2 code).  Since lbzip2 doesn't offer a library, I
guess each program has to have a copy of the code, and other system
tools will still use the bzip2 library.

I think the "right" way to move forward is to make a library that is at
least API-compatible with the current libbz2.so.1, make all the tools
use it, and just replace bzip2 with lbzip2.
-- 
Chris Adams <linux at cmadams.net>