node-liblzma 1.0.4 → 1.1.6

package/deps/xz/share/doc/xz/faq.txt

@@ -1,224 +0,0 @@
-
-XZ Utils FAQ
-============
-
-Q:  What do the letters XZ mean?
-
-A:  Nothing. They are just two letters, which come from the file format
-    suffix .xz. The .xz suffix was selected, because it seemed to be
-    pretty much unused. It has no deeper meaning.
-
-
-Q:  What are LZMA and LZMA2?
-
-A:  LZMA stands for Lempel-Ziv-Markov chain-Algorithm. It is the name
-    of the compression algorithm designed by Igor Pavlov for 7-Zip.
-    LZMA is based on LZ77 and range encoding.
-
-    LZMA2 is an updated version of the original LZMA to fix a couple of
-    practical issues. In context of XZ Utils, LZMA is called LZMA1 to
-    emphasize that LZMA is not the same thing as LZMA2. LZMA2 is the
-    primary compression algorithm in the .xz file format.
-
-
-Q:  There are many LZMA related projects. How does XZ Utils relate to them?
-
-A:  7-Zip and LZMA SDK are the original projects. LZMA SDK is roughly
-    a subset of the 7-Zip source tree.
-
-    p7zip is 7-Zip's command-line tools ported to POSIX-like systems.
-
-    LZMA Utils provide a gzip-like lzma tool for POSIX-like systems.
-    LZMA Utils are based on LZMA SDK. XZ Utils are the successor to
-    LZMA Utils.
-
-    There are several other projects using LZMA. Most are more or less
-    based on LZMA SDK. See <http://7-zip.org/links.html>.
-
-
-Q:  Why is liblzma named liblzma if its primary file format is .xz?
-    Shouldn't it be e.g. libxz?
-
-A:  When the designing of the .xz format began, the idea was to replace
-    the .lzma format and use the same .lzma suffix. It would have been
-    quite OK to reuse the suffix when there were very few .lzma files
-    around. However, the old .lzma format became popular before the
-    new format was finished. The new format was renamed to .xz but the
-    name of liblzma wasn't changed.
-
-
-Q:  Do XZ Utils support the .7z format?
-
-A:  No. Use 7-Zip (Windows) or p7zip (POSIX-like systems) to handle .7z
-    files.
-
-
-Q:  I have many .tar.7z files. Can I convert them to .tar.xz without
-    spending hours recompressing the data?
-
-A:  In the "extra" directory, there is a script named 7z2lzma.bash which
-    is able to convert some .7z files to the .lzma format (not .xz). It
-    needs the 7za (or 7z) command from p7zip. The script may silently
-    produce corrupt output if certain assumptions are not met, so
-    decompress the resulting .lzma file and compare it against the
-    original before deleting the original file!
-
-
-Q:  I have many .lzma files. Can I quickly convert them to the .xz format?
-
-A:  For now, no. Since XZ Utils supports the .lzma format, it's usually
-    not too bad to keep the old files in the old format. If you want to
-    do the conversion anyway, you need to decompress the .lzma files and
-    then recompress to the .xz format.
-
-    Technically, there is a way to make the conversion relatively fast
-    (roughly twice the time that normal decompression takes). Writing
-    such a tool would take quite a bit of time though, and would probably
-    be useful to only a few people. If you really want such a conversion
-    tool, contact Lasse Collin and offer some money.
-
-
-Q:  I have installed xz, but my tar doesn't recognize .tar.xz files.
-    How can I extract .tar.xz files?
-
-A:  xz -dc foo.tar.xz | tar xf -
-
-
-Q:  Can I recover parts of a broken .xz file (e.g. a corrupted CD-R)?
-
-A:  It may be possible if the file consists of multiple blocks, which
-    typically is not the case if the file was created in single-threaded
-    mode. There is no recovery program yet.
-
-
-Q:  Is (some part of) XZ Utils patented?
-
-A:  Lasse Collin is not aware of any patents that could affect XZ Utils.
-    However, due to the nature of software patents, it's not possible to
-    guarantee that XZ Utils isn't affected by any third party patent(s).
-
-
-Q:  Where can I find documentation about the file format and algorithms?
-
-A:  The .xz format is documented in xz-file-format.txt. It is a container
-    format only, and doesn't include descriptions of any non-trivial
-    filters.
-
-    Documenting LZMA and LZMA2 is planned, but for now, there is no other
-    documentation than the source code. Before you begin, you should know
-    the basics of LZ77 and range-coding algorithms. LZMA is based on LZ77,
-    but LZMA is a lot more complex. Range coding is used to compress
-    the final bitstream like Huffman coding is used in Deflate.
-
-
-Q:  I cannot find BCJ and BCJ2 filters. Don't they exist in liblzma?
-
-A:  BCJ filter is called "x86" in liblzma. BCJ2 is not included,
-    because it requires using more than one encoded output stream.
-    A streamable version of BCJ2-style filtering is planned.
-
-
-Q:  I need to use a script that runs "xz -9". On a system with 256 MiB
-    of RAM, xz says that it cannot allocate memory. Can I make the
-    script work without modifying it?
-
-A:  Set a default memory usage limit for compression. You can do it e.g.
-    in a shell initialization script such as ~/.bashrc or /etc/profile:
-
-        XZ_DEFAULTS=--memlimit-compress=150MiB
-        export XZ_DEFAULTS
-
-    xz will then scale the compression settings down so that the given
-    memory usage limit is not reached. This way xz shouldn't run out
-    of memory.
-
-    Check also that memory-related resource limits are high enough.
-    On most systems, "ulimit -a" will show the current resource limits.
-
-
-Q:  How do I create files that can be decompressed with XZ Embedded?
-
-A:  See the documentation in XZ Embedded. In short, something like
-    this is a good start:
-
-        xz --check=crc32 --lzma2=preset=6e,dict=64KiB
-
-    Or if a BCJ filter is needed too, e.g. if compressing
-    a kernel image for PowerPC:
-
-        xz --check=crc32 --powerpc --lzma2=preset=6e,dict=64KiB
-
-    Adjust the dictionary size to get a good compromise between
-    compression ratio and decompressor memory usage. Note that
-    in single-call decompression mode of XZ Embedded, a big
-    dictionary doesn't increase memory usage.
-
-
-Q:  Will xz support threaded compression?
-
-A:  It is planned and has been taken into account when designing
-    the .xz file format. Eventually there will probably be three types
-    of threading, each method having its own advantages and disadvantages.
-
-    The simplest method is splitting the uncompressed data into blocks
-    and compressing them in parallel independent from each other.
-    Since the blocks are compressed independently, they can also be
-    decompressed independently. Together with the index feature in .xz,
-    this allows using threads to create .xz files for random-access
-    reading. This also makes threaded decompression possible, although
-    it is not clear if threaded decompression will ever be implemented.
-
-    The independent blocks method has a couple of disadvantages too. It
-    will compress worse than a single-block method. Often the difference
-    is not too big (maybe 1-2 %) but sometimes it can be too big. Also,
-    the memory usage of the compressor increases linearly when adding
-    threads.
-
-    Match finder parallelization is another threading method. It has
-    been in 7-Zip for ages. It doesn't affect compression ratio or
-    memory usage significantly. Among the three threading methods, only
-    this is useful when compressing small files (files that are not
-    significantly bigger than the dictionary). Unfortunately this method
-    scales only to about two CPU cores.
-
-    The third method is pigz-style threading (I use that name, because
-    pigz <http://www.zlib.net/pigz/> uses that method). It doesn't
-    affect compression ratio significantly and scales to many cores.
-    The memory usage scales linearly when threads are added. This isn't
-    significant with pigz, because Deflate uses only a 32 KiB dictionary,
-    but with LZMA2 the memory usage will increase dramatically just like
-    with the independent-blocks method. There is also a constant
-    computational overhead, which may make pigz-method a bit dull on
-    dual-core compared to the parallel match finder method, but with more
-    cores the overhead is not a big deal anymore.
-
-    Combining the threading methods will be possible and also useful.
-    E.g. combining match finder parallelization with pigz-style threading
-    can cut the memory usage by 50 %.
-
-    It is possible that the single-threaded method will be modified to
-    create files identical to the pigz-style method. We'll see once
-    pigz-style threading has been implemented in liblzma.
-
-
-Q:  How do I build a program that needs liblzmadec (lzmadec.h)?
-
-A:  liblzmadec is part of LZMA Utils. XZ Utils has liblzma, but no
-    liblzmadec. The code using liblzmadec should be ported to use
-    liblzma instead. If you cannot or don't want to do that, download
-    LZMA Utils from <http://tukaani.org/lzma/>.
-
-
-Q:  The default build of liblzma is too big. How can I make it smaller?
-
-A:  Give --enable-small to the configure script. Use also appropriate
-    --enable or --disable options to include only those filter encoders
-    and decoders and integrity checks that you actually need. Use
-    CFLAGS=-Os (with GCC) or equivalent to tell your compiler to optimize
-    for size. See INSTALL for information about configure options.
-
-    If the result is still too big, take a look at XZ Embedded. It is
-    a separate project, which provides a limited but significantly
-    smaller XZ decoder implementation than XZ Utils. You can find it
-    at <http://tukaani.org/xz/embedded.html>.
-

package/deps/xz/share/doc/xz/history.txt

@@ -1,150 +0,0 @@
-
-History of LZMA Utils and XZ Utils
-==================================
-
-Tukaani distribution
-
-    In 2005, there was a small group working on the Tukaani distribution,
-    which was a Slackware fork. One of the project's goals was to fit the
-    distro on a single 700 MiB ISO-9660 image. Using LZMA instead of gzip
-    helped a lot. Roughly speaking, one could fit data that took 1000 MiB
-    in gzipped form into 700 MiB with LZMA. Naturally, the compression
-    ratio varied across packages, but this was what we got on average.
-
-    Slackware packages have traditionally had .tgz as the filename suffix,
-    which is an abbreviation of .tar.gz. A logical naming for LZMA
-    compressed packages was .tlz, being an abbreviation of .tar.lzma.
-
-    At the end of the year 2007, there was no distribution under the
-    Tukaani project anymore, but development of LZMA Utils was kept going.
-    Still, there were .tlz packages around, because at least Vector Linux
-    (a Slackware based distribution) used LZMA for its packages.
-
-    First versions of the modified pkgtools used the LZMA_Alone tool from
-    Igor Pavlov's LZMA SDK as is. It was fine, because users wouldn't need
-    to interact with LZMA_Alone directly. But people soon wanted to use
-    LZMA for other files too, and the interface of LZMA_Alone wasn't
-    comfortable for those used to gzip and bzip2.
-
-
-First steps of LZMA Utils
-
-    The first version of LZMA Utils (4.22.0) included a shell script called
-    lzmash. It was a wrapper that had a gzip-like command-line interface. It
-    used the LZMA_Alone tool from LZMA SDK to do all the real work. zgrep,
-    zdiff, and related scripts from gzip were adapted to work with LZMA and
-    were part of the first LZMA Utils release too.
-
-    LZMA Utils 4.22.0 included also lzmadec, which was a small (less than
-    10 KiB) decoder-only command-line tool. It was written on top of the
-    decoder-only C code found from the LZMA SDK. lzmadec was convenient in
-    situations where LZMA_Alone (a few hundred KiB) would be too big.
-
-    lzmash and lzmadec were written by Lasse Collin.
-
-
-Second generation
-
-    The lzmash script was an ugly and not very secure hack. The last
-    version of LZMA Utils to use lzmash was 4.27.1.
-
-    LZMA Utils 4.32.0beta1 introduced a new lzma command-line tool written
-    by Ville Koskinen. It was written in C++, and used the encoder and
-    decoder from C++ LZMA SDK with some little modifications. This tool
-    replaced both the lzmash script and the LZMA_Alone command-line tool
-    in LZMA Utils.
-
-    Introducing this new tool caused some temporary incompatibilities,
-    because the LZMA_Alone executable was simply named lzma like the new
-    command-line tool, but they had a completely different command-line
-    interface. The file format was still the same.
-
-    Lasse wrote liblzmadec, which was a small decoder-only library based
-    on the C code found from LZMA SDK. liblzmadec had an API similar to
-    zlib, although there were some significant differences, which made it
-    non-trivial to use it in some applications designed for zlib and
-    libbzip2.
-
-    The lzmadec command-line tool was converted to use liblzmadec.
-
-    Alexandre Sauvé helped converting the build system to use GNU
-    Autotools. This made it easier to test for certain less portable
-    features needed by the new command-line tool.
-
-    Since the new command-line tool never got completely finished (for
-    example, it didn't support the LZMA_OPT environment variable), the
-    intent was to not call 4.32.x stable. Similarly, liblzmadec wasn't
-    polished, but appeared to work well enough, so some people started
-    using it too.
-
-    Because the development of the third generation of LZMA Utils was
-    delayed considerably (3-4 years), the 4.32.x branch had to be kept
-    maintained. It got some bug fixes now and then, and finally it was
-    decided to call it stable, although most of the missing features were
-    never added.
-
-
-File format problems
-
-    The file format used by LZMA_Alone was primitive. It was designed with
-    embedded systems in mind, and thus provided only a minimal set of
-    features. The two biggest problems for non-embedded use were the lack
-    of magic bytes and an integrity check.
-
-    Igor and Lasse started developing a new file format with some help
-    from Ville Koskinen. Also Mark Adler, Mikko Pouru, H. Peter Anvin,
-    and Lars Wirzenius helped with some minor things at some point of the
-    development. Designing the new format took quite a long time (actually,
-    too long a time would be a more appropriate expression). It was mostly
-    because Lasse was quite slow at getting things done due to personal
-    reasons.
-
-    Originally the new format was supposed to use the same .lzma suffix
-    that was already used by the old file format. Switching to the new
-    format wouldn't have caused much trouble when the old format wasn't
-    used by many people. But since the development of the new format took
-    such a long time, the old format got quite popular, and it was decided
-    that the new file format must use a different suffix.
-
-    It was decided to use .xz as the suffix of the new file format. The
-    first stable .xz file format specification was finally released in
-    December 2008. In addition to fixing the most obvious problems of
-    the old .lzma format, the .xz format added some new features like
-    support for multiple filters (compression algorithms), filter chaining
-    (like piping on the command line), and limited random-access reading.
-
-    Currently the primary compression algorithm used in .xz is LZMA2.
-    It is an extension on top of the original LZMA to fix some practical
-    problems: LZMA2 adds support for flushing the encoder, uncompressed
-    chunks, eases stateful decoder implementations, and improves support
-    for multithreading. Since LZMA2 is better than the original LZMA, the
-    original LZMA is not supported in .xz.
-
-
-Transition to XZ Utils
-
-    The early versions of XZ Utils were called LZMA Utils. The first
-    releases were 4.42.0alphas. They dropped the rest of the C++ LZMA SDK.
-    The code was still directly based on LZMA SDK but ported to C and
-    converted from a callback API to a stateful API. Later, Igor Pavlov
-    made a C version of the LZMA encoder too; these ports from C++ to C
-    were independent in LZMA SDK and LZMA Utils.
-
-    The core of the new LZMA Utils was liblzma, a compression library with
-    a zlib-like API. liblzma supported both the old and new file format.
-    The gzip-like lzma command-line tool was rewritten to use liblzma.
-
-    The new LZMA Utils code base was renamed to XZ Utils when the name
-    of the new file format had been decided. The liblzma compression
-    library retained its name though, because changing it would have
-    caused unnecessary breakage in applications already using the early
-    liblzma snapshots.
-
-    The xz command-line tool can emulate the gzip-like lzma tool by
-    creating appropriate symlinks (e.g. lzma -> xz). Thus, practically
-    all scripts using the lzma tool from LZMA Utils will work as is with
-    XZ Utils (and will keep using the old .lzma format). Still, the .lzma
-    format is more or less deprecated. XZ Utils will keep supporting it,
-    but new applications should use the .xz format, and migrating old
-    applications to .xz is often a good idea too.
-

package/deps/xz/share/doc/xz/lzma-file-format.txt

@@ -1,166 +0,0 @@
-
-The .lzma File Format
-=====================
-
-        0. Preface
-           0.1. Notices and Acknowledgements
-           0.2. Changes
-        1. File Format
-           1.1. Header
-                1.1.1. Properties
-                1.1.2. Dictionary Size
-                1.1.3. Uncompressed Size
-           1.2. LZMA Compressed Data
-        2. References
-
-
-0. Preface
-
-        This document describes the .lzma file format, which is
-        sometimes also called LZMA_Alone format. It is a legacy file
-        format, which is being or has been replaced by the .xz format.
-        The MIME type of the .lzma format is `application/x-lzma'.
-
-        The most commonly used software to handle .lzma files are
-        LZMA SDK, LZMA Utils, 7-Zip, and XZ Utils. This document
-        describes some of the differences between these implementations
-        and gives hints what subset of the .lzma format is the most
-        portable.
-
-
-0.1. Notices and Acknowledgements
-
-        This file format was designed by Igor Pavlov for use in
-        LZMA SDK. This document was written by Lasse Collin
-        <lasse.collin@tukaani.org> using the documentation found
-        from the LZMA SDK.
-
-        This document has been put into the public domain.
-
-
-0.2. Changes
-
-        Last modified: 2011-04-12 11:55+0300
-
-
-1. File Format
-
-        +-+-+-+-+-+-+-+-+-+-+-+-+-+==========================+
-        |         Header          |   LZMA Compressed Data   |
-        +-+-+-+-+-+-+-+-+-+-+-+-+-+==========================+
-
-        The .lzma format file consist of 13-byte Header followed by
-        the LZMA Compressed Data.
-
-        Unlike the .gz, .bz2, and .xz formats, it is not possible to
-        concatenate multiple .lzma files as is and expect the
-        decompression tool to decode the resulting file as if it were
-        a single .lzma file.
-
-        For example, the command line tools from LZMA Utils and
-        LZMA SDK silently ignore all the data after the first .lzma
-        stream. In contrast, the command line tool from XZ Utils
-        considers the .lzma file to be corrupt if there is data after
-        the first .lzma stream.
-
-
-1.1. Header
-
-        +------------+----+----+----+----+--+--+--+--+--+--+--+--+
-        | Properties |  Dictionary Size  |   Uncompressed Size   |
-        +------------+----+----+----+----+--+--+--+--+--+--+--+--+
-
-
-1.1.1. Properties
-
-        The Properties field contains three properties. An abbreviation
-        is given in parentheses, followed by the value range of the
-        property. The field consists of
-
-            1) the number of literal context bits (lc, [0, 8]);
-            2) the number of literal position bits (lp, [0, 4]); and
-            3) the number of position bits (pb, [0, 4]).
-
-        The properties are encoded using the following formula:
-
-            Properties = (pb * 5 + lp) * 9 + lc
-
-        The following C code illustrates a straightforward way to
-        decode the Properties field:
-
-            uint8_t lc, lp, pb;
-            uint8_t prop = get_lzma_properties();
-            if (prop > (4 * 5 + 4) * 9 + 8)
-                return LZMA_PROPERTIES_ERROR;
-
-            pb = prop / (9 * 5);
-            prop -= pb * 9 * 5;
-            lp = prop / 9;
-            lc = prop - lp * 9;
-
-        XZ Utils has an additional requirement: lc + lp <= 4. Files
-        which don't follow this requirement cannot be decompressed
-        with XZ Utils. Usually this isn't a problem since the most
-        common lc/lp/pb values are 3/0/2. It is the only lc/lp/pb
-        combination that the files created by LZMA Utils can have,
-        but LZMA Utils can decompress files with any lc/lp/pb.
-
-
-1.1.2. Dictionary Size
-
-        Dictionary Size is stored as an unsigned 32-bit little endian
-        integer. Any 32-bit value is possible, but for maximum
-        portability, only sizes of 2^n and 2^n + 2^(n-1) should be
-        used.
-
-        LZMA Utils creates only files with dictionary size 2^n,
-        16 <= n <= 25. LZMA Utils can decompress files with any
-        dictionary size.
-
-        XZ Utils creates and decompresses .lzma files only with
-        dictionary sizes 2^n and 2^n + 2^(n-1). If some other
-        dictionary size is specified when compressing, the value
-        stored in the Dictionary Size field is a rounded up, but the
-        specified value is still used in the actual compression code.
-
-
-1.1.3. Uncompressed Size
-
-        Uncompressed Size is stored as unsigned 64-bit little endian
-        integer. A special value of 0xFFFF_FFFF_FFFF_FFFF indicates
-        that Uncompressed Size is unknown. End of Payload Marker (*)
-        is used if and only if Uncompressed Size is unknown.
-
-        XZ Utils rejects files whose Uncompressed Size field specifies
-        a known size that is 256 GiB or more. This is to reject false
-        positives when trying to guess if the input file is in the
-        .lzma format. When Uncompressed Size is unknown, there is no
-        limit for the uncompressed size of the file.
-
-        (*) Some tools use the term End of Stream (EOS) marker
-            instead of End of Payload Marker.
-
-
-1.2. LZMA Compressed Data
-
-        Detailed description of the format of this field is out of
-        scope of this document.
-
-
-2. References
-
-        LZMA SDK - The original LZMA implementation
-        http://7-zip.org/sdk.html
-
-        7-Zip
-        http://7-zip.org/
-
-        LZMA Utils - LZMA adapted to POSIX-like systems
-        http://tukaani.org/lzma/
-
-        XZ Utils - The next generation of LZMA Utils
-        http://tukaani.org/xz/
-
-        The .xz file format - The successor of the .lzma format
-        http://tukaani.org/xz/xz-file-format.txt
-