Re: RFS: lbzip2
On Fri, Feb 13, 2009 at 9:59 PM, ERSEK Laszlo <lacos@elte.hu> wrote:
> I believe I wasn't exact enough. If your compressed input has *any* of the
> following characterists, pbzip2 won't use multiple worker threads to
> decompress it, while lbzip2 will:
> (1) The compressed input is read from a pipe.
> (2) The compressed input consists of a single pbzip2 stream.
....
> As a further, experimental proof, please look at the my reports that were
> created for tests that used pbzip2-1.0.5:
> - report_alpha_osf1.txt
> - report_sparc_solaris.txt
> - report_x86_linux.txt
>
> Citing the "Version", "File size [B]" and "Decompr. speed [%]" blocks from
> "report_alpha_osf1.txt" (I mark the relevant rows with exlamation marks
> now):
Ok, these numbers convinced me lbzip2 is better.
>> http://compression.ca/pbzip2/
>
> I invited him a while ago to look at lbzip2 (on 16 Oct 2008). At that time
> lbzip2 already had an input bound splitter (I mentioned that in my first
> mail to Jeff.)
Thanks for the analysis.
>> Based on your list, it looks like lbzip2 has no advantage over pbzip2?
>
> In some cases, it does have an advantage; see above.
Agreed.
>> The report URLs give errors when requested. Same with the download link.
>
> Strange. Please try http://lacos.web.elte.hu/pub/lbzip2/ then (which is also
> the URL I put in debian/watch).
Those work.
>> If you could talk to the bzip2 upstream and all the people who rewrote it
>> to add parallelism and convince them to all work on adding parallelism
>> to bzip2, that would be a really great contribution to the world of
>> free software. Same for gzip/pigz.
>
> I agree.
If you could make getting the lbzip2 design (since it seems better
than pbzip2, please evaluate the other ones too) for bzip2 parallelism
into bzip2 itself your long-term goal, it would be great. Until
you/someone does so, lets add lbzip2 to Debian.
And now onto the package review:
Why does your diff.gz patch the Makefile? Shouldn't you add those
changes to the upstream Makefile?
About the manual page patch, would it be possible to make the upstream
build process configurable so that you don't need to patch in the
path?
Shouldn't the upstream Makefile also install the manual page?
You are missing a Homepage field.
You need ${misc:Depends} in your Depends line, in case one of the
debhelper scripts you use starts adding something to it and you don't
notice.
noopt should add -O0 to the CFLAGS and nostrip is handled by dh_strip
so you don't need to do it as long as you always make gcc put
debugging symbols in.
Shouldn't LIBS be something the upstream Makefile sets?
Why do you install all the files in /usr/share/lbzip2 ?
I'm not comfortable uploading this without a test suite being run
during the package build process.
lintian -I -E --pedantic --show-overrides:
P: lbzip2 source: direct-changes-in-diff-but-no-patch-system Makefile and 1 more
P: lbzip2: copyright-refers-to-symlink-license usr/share/common-licenses/GPL
I: lbzip2: copyright-with-old-dh-make-debian-copyright
I: lbzip2: binary-has-unneeded-section ./usr/bin/lbzip2 .comment
P: lbzip2: no-homepage-field
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: