On Tue, May 18, 2010 at 03:38:47PM -0500, Shawn Walker wrote: ... > 4.3.8. Package Archive Index Specification: > > The pkg(5) archive index file enables fast, efficient access > to the contents of an archive. It contains an entry for all > files in the archive excluding the index file itself in the > following format (also referred to as index format version > 0): > > <name>NUL<offset>NUL<entry_size>NUL<size>NUL<typeflag>NL > > <name> is a string containing the pathname of the file > in the archive using only ascii characters. It can be > up to 65,535 bytes in length. > > <offset> is an unsigned long long integer in string form > containing the relative offset in bytes of the first > header block for the file in the archive. The offset is > relative to the end of the last block of the index file > in the archive they are listed in.
Just trying to make sure I understand this. The ustar header gives you the offset and the size for the first archive index. The last entry in the archive index must point to another index, if one exists. The index files are zero padded to 256 bytes. If you have multiple archive index files, how do you find the next index without scanning through the first index? Is this possible, or have I misunderstood part of how this works? When you're adding files to an archive, is it ever possible for the new index file to reference files that are already present in the archive? If so, you'd have a negative offset relative to the end of the new archive index. This would be confusing and error prone, IMO. > 5.4. Client and Depot Support for On-Disk Archive Format: > > The pkg.server.repository module will be updated to support > the serving of a repository in readonly mode using a pkg(5) > archive file. > > The pkg.client.api transport system will be updated to support > the usage of a pkg(5) archive file as an origin for package > data. When multiple origins are present for a publisher, they > will be checked in this order of preference for package data: > > - local client cache > - pkg(5) archive files > - remaining origins and mirrors I'm okay with specifying that the local client cache is accessed first; however, I don't think it's appropriate to define the order in which any mirrors and origins will be accessed. This should be handled by the quality measurement system in the transport. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
