On Fri, Jun 30, 2006 at 07:22:53PM +0900, [email protected] wrote:
there some other reason?
It’s a good solution in practice for many reasons; here’s the answer I
a similar question on [ruby-core:6258]:
[...] here are the pros I can think of:
* the format is extensible because it's possible to add new entries
“outer” tarball. This has proved useful already: the package
just contained metadata.gz and data.tar.gz, and recently
and metadata.gz.sig have been added to support signatures.
* it is easy to extract the metadata without uncompressing the whole
* it’s possible to write data.tar.gz and generate the file lists and
information dynamically before writing metadata.gz, while
being written. It is thus be possible to store for instance a
cryptographic digest of the data.tar.gz file in metadata.gz. This
be somewhat harder if the metadata were included in a single
especially if we compressed it.
* it takes little time to locate metadata.gz inside the tarball
to go through many more entries if it were a flat tarball). While
is still O(n), n is the number of entries in the outer file (2
originally, now 4) instead of the normally much more numerous data
Also, note that the code in package.rb was written carefully to
having to keep the full contents of the archive (or any contained
memory at any point in time (with the exception of metadata.gz, of
course). RubyGems doesn’t exploit that ability since the first thing
does before unpacking is uncompressing all the data and storing it
array, but package.rb would have supported O(1) memory usage. That’s
metadata.gz comes after data.tar.gz inside the .gem.
Also, on [ruby-core:6251]:
The "nested tarball" format was inspired by Debian's .deb format.
latter uses ar for the outer layer, but I saw no reason to implement
another subformat. When I originally hacked the package format for
rpa-base, I used nested zip files; I changed that to use POSIX
when I discovered that RubyZip triggered a bug in Tempfile that
cause ruby to use over 100MB RAM to create a 300KB .zip file. That
fixed quickly, but by then there was no reason to change the package
format again. Had this bug not been there, maybe RubyGems would be