Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(112)

Unified Diff: doc/history.txt

Issue 12568011: Update XZ Utils to 5.0.4 (third_party) (Closed) Base URL: svn://svn.chromium.org/chrome/trunk/deps/third_party/xz/
Patch Set: Created 7 years, 9 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View side-by-side diff with in-line comments
Download patch
« README.chromium ('K') | « doc/faq.txt ('k') | dos/Makefile » ('j') | no next file with comments »
Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
Index: doc/history.txt
===================================================================
--- doc/history.txt (revision 87706)
+++ doc/history.txt (working copy)
@@ -4,12 +4,12 @@
Tukaani distribution
- In 2005, there was a small group working on Tukaani distribution, which
- was a Slackware fork. One of the project 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 compression ratio varied across
- packages, but this was what we got on average.
+ 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
@@ -30,13 +30,13 @@
First steps of LZMA Utils
The first version of LZMA Utils (4.22.0) included a shell script called
- lzmash. It was wrapper that had gzip-like command line interface. It
+ 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 work with LZMA and
+ 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
+ 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.
@@ -48,33 +48,34 @@
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
+ 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 little modifications. This tool replaced
- both the lzmash script and the LZMA_Alone command line tool in LZMA
- Utils.
+ 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 LZMA_Alone executable was simply named lzma like the new
- command line tool, but they had completely different command line
+ 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 API similar to zlib,
- although there were some significant differences, which made it
+ 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.
+ The lzmadec command-line tool was converted to use liblzmadec.
- Alexandre Sauvé helped converting build system to use GNU Autotools.
- This made is easier to test for certain less portable features needed
- by the new command line tool.
+ 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 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.
+ 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
@@ -85,16 +86,16 @@
File format problems
- The file format used by LZMA_Alone was primitive. It was designed for
- embedded systems in mind, and thus provided only minimal set of
- features. The two biggest problems for non-embedded use were lack of
- magic bytes and integrity check.
+ 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 time would be more appropriate expression). It was mostly
+ 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.
@@ -102,7 +103,7 @@
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
- so long time, the old format got quite popular, and it was decided
+ 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
@@ -125,13 +126,13 @@
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 callback API to stateful API. Later, Igor Pavlov made
- C version of the LZMA encoder too; these ports from C++ to C were
- independent in LZMA SDK and LZMA Utils.
+ 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
- zlib-like API. liblzma supported both the old and new file format. The
- gzip-like lzma command line tool was rewritten to use liblzma.
+ 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
@@ -139,7 +140,7 @@
caused unnecessary breakage in applications already using the early
liblzma snapshots.
- The xz command line tool can emulate the gzip-like lzma tool by
+ 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
« README.chromium ('K') | « doc/faq.txt ('k') | dos/Makefile » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698