[Rpm-maint] rpm: support lzip compression for %setup (patch)

Jan Engelhardt jengelh at medozas.de
Wed Dec 17 13:21:53 UTC 2008

On Wednesday 2008-12-17 12:53, Panu Matilainen wrote:

> On Sat, 29 Nov 2008, Ralf Corsepius wrote:
>> On Wed, 2008-11-26 at 22:55 +0100, Jan Engelhardt wrote:
>> > LZIP is the new stable lzma compression utility
>> Pardon, but what is your legitimation to claim lzip to be
>> "the new stable lzma compression utility"?
>> No doubt, it is "yet one another lzma" compression utility.
>> >
>> > ( http://freshmeat.net/p/lzip/ ) with magic bytes and checksum.
>> IMO, rpm should not adopt lzip  support, unless lzip has proven to be a
>> functional and viable tool.
>> See also:
>> http://lists.gnu.org/archive/html/automake/2008-11/msg00076.html
>> FWIW: I share Bob F's perspective. One lesson the mess about the
>> original lzma has tought, is to be more reluctant on adoption of such
>> compression tools.
> Wrt compressors for use in rpm payloads, absolutely agreed. Build-time support
> for uncompressing patches + tarballs for whatever formats is quite different
> issue and not harmful, but I see little point in having support for a format
> that barely exists in the wild (AFAICT).

There must be some kind of universal law that states that projects
(I'm not even talking 'bout compressors) that have >N% "attention
market share" get even more attention no matter how 'bad' they are,
and that projects having less than those N% get no attention at all
because everybody claims "no one uses it so what". That way, projects
that are just recently nascent can hardly take off no matter how
'good' they may be.

> Otherwise we should add LHA, ARJ and
> all the other myriads of known (un)compressors too...

These belong to the set of tools that faded away. LZH and ARJ were
absolutely normal in the 90s and not having an uncompressor for them
on your DOS system meant you suck, because, (at least ARJ) did often
provide better compression than PKZIP. As time passed, tools with
other distinct features arose, such as (as CRC was already there)
archive repair metadata, or even higher compression ratios.

More information about the Rpm-maint mailing list