* [gentoo-pms] xpak documentation
@ 2009-02-01 10:48 Lars Hartmann
2009-02-01 14:53 ` Ciaran McCreesh
0 siblings, 1 reply; 3+ messages in thread
From: Lars Hartmann @ 2009-02-01 10:48 UTC (permalink / raw
To: gentoo-pms
[-- Attachment #1.1: Type: text/plain, Size: 598 bytes --]
Hi,
i have stumbled across this document a few days ago and realized that
there is no documentation for the xpak format as used in gentoo binary
packages.
Attached is a technical documentation of the xpak format i have written
some time ago, that you could use as a source if you want, as i am the
only author of it, i could also give you permission to redistribute it
under whatever license you want.
Greetings Lars Hartmann
--
/"\ ASCII Ribbon Campaign
\ / Respect for low technology.
X Keep e-mail messages readable by any computer system.
/ \ Keep it ASCII.
[-- Attachment #1.2: xpak.txt --]
[-- Type: text/x-vhdl, Size: 7339 bytes --]
+-----------------------------------------------------------------------------+
| Copyright (c) 2008, Lars Hartmann |
| All rights reserved. |
| |
| Redistribution and use in source and binary forms, with or without |
| modification, are permitted provided that the following conditions are met: |
| |
| 1. Redistributions of source code must retain the above copyright |
| notice, this list of conditions and the following disclaimer. |
| |
| 2. Redistributions in binary form must reproduce the above copyright |
| notice, this list of conditions and the following disclaimer in the |
| documentation and/or other materials provided with the distribution. |
| |
| 3. Neither the name of the Original Author, nor the names of its |
| contributors may be used to endorse or promote products derived from |
| this software without specific prior written permission. |
| |
| THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" |
| AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE |
| IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE |
| ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE |
| LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR |
| CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF |
| SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS |
| INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN |
| CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) |
| ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE |
| POSSIBILITY OF SUCH DAMAGE. |
+-----------------------------------------------------------------------------+
The XPAK Data Format
====================
Notes
=====
Data Types
==========
Integer: every offset or length(len) value in this documentation will be an
unsigned 32bit integer in big endian byte order(32bit unsigned big
int or uint32(big) ).
String: All Strings, Mentioned in this Documentation are ASCII encoded, and
not Null terminated
Values: The actual values of the individual xpak entries are stored as
Strings.
Vertical Bars
=============
The vertical bars '|' are not part of the file format, they are merely used
to illustrate how the offset values apply to the data.
Synopsis
========
<tarball>: |<-xpak_offset->|
<tar>|< xpak >|<xpak_offset>"STOP"
<xpak> : "XPAKPACK"<index_len><data_len><index><data>"XPAKSTOP"
<index> : |<-------------index_len------------->|
|<index1><index2><index3><index4><...>|
<indexN> : |<-name_len->|
<name_len>|< name >|<data_offset><data_len>
<data> : |<--------------data_len------------->|
|<-dataN_offset->|<-dataN_len->|
|< data >|< data_N >|<data>|
Detailed
========
Every gentoo binary package has a xpak attached to it which contains build
time information like the use flags it was built with, the ebuild it was
built from, the environmental variables, CFLAGs, CXXFLAGs, ....
lets have a look at this XPAK:
If you look at a gentoo binary package (binpkg) with a hex-editor you'll
notice the that after the data, which belongs to the tarball you find a
binary blob - the <xpak>, an offset which holds the bytes from the start of
the <xpak> to the end of the file - <xpak_offset> and finally the String
"STOP":
|<-xpak_offset->|
<tbz2>|< xpak >|<xpak_offset>"STOP"|
Here you see the tbz2 archive, and the attached xpak-blob, the xpak-offset
and the string "STOP" at the end.
If we read the offset and count <offset> bytes backwards from the start of
xpak_offset, we have found the start of the XPAK Block which starts with the
String "XPAKPACK". this xpak block consists of the string "XPAKPACK", the
length of the index block - <index-len>, the length of the data block -
<data-len>, a <index-len> bytes long binary blob which holds the index, a
<data-len> bytes long binary blob which holds the data and the String
"XPAKSTOP" at the end:
|<-index_len->|<-data_len->|
"XPAKPACK"<index_len><data_len>|< index >|< data >|"XPAKSTOP"
To actually get the index and the data, we cut out <index_len> bytes, after
the end of <data_len> and for the index block and cut out the next <data_len>
bytes for the data block. If we have done everything right up to this point,
the following bytes would be the ASCII formatted string "XPAKSTOP".
The actual data is truncated to one big block - so if we want to read it we
need the actual positions of each information in this big data block, this
information can be obtained from the indices which are stored in the index
block.
Now we take a closer look at the index block:
The index block consists of several truncated index blocks:
|<-----------------------index_len---------------------->|
|<index1><index2><index3><index4><index5><index6><index7>|
The index block holds all information we need to find the data we want in the
<data> block. It consists of truncated index elements with a length
<index_len>. Each of those index elements stands for one information in the
data block and consists of the length of its name - <name_len>, a <name_len>
bytes long String - the Name of the data block, this index belongs to, the
offset of the data block (counted from the beginning of <data>) -
<data_offset>, and the length of that data block - <data_len>:
|<-name_len->|
<name_len>|< name >|<dataN_offset><dataN_len>
Now lets take a closer look at the data block: the data block contains
truncated data blocks with a total length of <data_len>:
|<------------------------data_len------------------------>|
|<data1><data2><data3><data4><data5><data6><data7><data...>|
This binary block with a length of <data_len> bytes, consists of truncated
data.
To select one data element, we need the <data_offset> and the <data_len> from
the index, if we have those we can count <data_offset> bytes from the start
of the data block, and then cut out the next <data_len> bytes. there we got
our data Block:
|<-----dataN_offset----->|<--dataN_len->|
|<data1data2data3data...>|<data-we-want>|
[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [gentoo-pms] xpak documentation
2009-02-01 10:48 [gentoo-pms] xpak documentation Lars Hartmann
@ 2009-02-01 14:53 ` Ciaran McCreesh
2009-02-01 15:18 ` Lars Hartmann
0 siblings, 1 reply; 3+ messages in thread
From: Ciaran McCreesh @ 2009-02-01 14:53 UTC (permalink / raw
To: gentoo-pms
[-- Attachment #1: Type: text/plain, Size: 404 bytes --]
On Sun, 01 Feb 2009 11:48:41 +0100
Lars Hartmann <lars@chaotika.org> wrote:
> i have stumbled across this document a few days ago and realized that
> there is no documentation for the xpak format as used in gentoo binary
> packages.
Mm, that's because I'm not convinced the binary format Portage uses
just now is standard-worthy. I'd rather keep PMS restricted in scope.
--
Ciaran McCreesh
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [gentoo-pms] xpak documentation
2009-02-01 14:53 ` Ciaran McCreesh
@ 2009-02-01 15:18 ` Lars Hartmann
0 siblings, 0 replies; 3+ messages in thread
From: Lars Hartmann @ 2009-02-01 15:18 UTC (permalink / raw
To: gentoo-pms
[-- Attachment #1: Type: text/plain, Size: 850 bytes --]
I am wondering about the following two points:
1. Is there an effort to define a standard for binary packages
especially the way how the metadata are attached?
2. Are there any other alternatives to xpak?
Am Sonntag, den 01.02.2009, 14:53 +0000 schrieb Ciaran McCreesh:
> On Sun, 01 Feb 2009 11:48:41 +0100
> Lars Hartmann <lars@chaotika.org> wrote:
> > i have stumbled across this document a few days ago and realized that
> > there is no documentation for the xpak format as used in gentoo binary
> > packages.
>
> Mm, that's because I'm not convinced the binary format Portage uses
> just now is standard-worthy. I'd rather keep PMS restricted in scope.
>
--
/"\ ASCII Ribbon Campaign
\ / Respect for low technology.
X Keep e-mail messages readable by any computer system.
/ \ Keep it ASCII.
[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-02-01 15:18 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-02-01 10:48 [gentoo-pms] xpak documentation Lars Hartmann
2009-02-01 14:53 ` Ciaran McCreesh
2009-02-01 15:18 ` Lars Hartmann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox