| 1 |
Hi, |
| 2 |
|
| 3 |
Ok, here's the second version integrating the feedback received. |
| 4 |
The format is much simpler, based on nested tarballs inspired by Debian. |
| 5 |
|
| 6 |
The outer tarball is uncompressed and uses '.gpkg.tar' suffix. It |
| 7 |
contains (preferably in order but PM should also handle packages with |
| 8 |
mismatched order): |
| 9 |
|
| 10 |
1. Optional (but recommended) "gpkg: ${PF}" package label that can be |
| 11 |
used to quickly distinguish Gentoo binpkgs from regular tarballs |
| 12 |
(for file(1)). |
| 13 |
|
| 14 |
2. "metadata.tar${comp}" tarball containing binary package metadata |
| 15 |
as files. |
| 16 |
|
| 17 |
3. Optional "metadata.tar${comp}.sig" containing detached signature |
| 18 |
for the metadata archive. |
| 19 |
|
| 20 |
4. "contents.tar${comp}" tarball containing files to be installed. |
| 21 |
|
| 22 |
5. Optional "contents.tar${comp}.sig" containing detached signature for |
| 23 |
the contents archive. |
| 24 |
|
| 25 |
Notes: |
| 26 |
|
| 27 |
a. ${comp} can be any compression format supported by binary packages. |
| 28 |
Technically, metadata and content archives may use different |
| 29 |
compression. Either or both may be uncompressed as well. |
| 30 |
|
| 31 |
b. While signatures are optional, the PM should have a switch |
| 32 |
controlling whether to expect them, and fail hard if they're not present |
| 33 |
when expected. |
| 34 |
|
| 35 |
|
| 36 |
Advantages |
| 37 |
---------- |
| 38 |
Guaranteed: |
| 39 |
|
| 40 |
+ The binary package is still one file, so can be fetched easily. |
| 41 |
|
| 42 |
+ File format is trivial and can be extracted using tar(1) + compressor. |
| 43 |
|
| 44 |
+ The metadata and contents are compressed independently, and so can be |
| 45 |
easily extracted or modified independently. |
| 46 |
|
| 47 |
+ The package format provides for separate metadata and content |
| 48 |
signatures, so they can be verified independently. |
| 49 |
|
| 50 |
+ Metadata can be compressed now. |
| 51 |
|
| 52 |
Achieved by regular archives (but might be broken if modified by user): |
| 53 |
|
| 54 |
+ Easy recognition by magic(1). |
| 55 |
|
| 56 |
+ The metadata archive (and its signature) is packed first, so it may be |
| 57 |
read without fetching the whole binpkg. |
| 58 |
|
| 59 |
|
| 60 |
Why not .ar format? |
| 61 |
------------------- |
| 62 |
The use of .ar format has been proposed, akin to Debian. While |
| 63 |
the option is mostly feasible, and the simplicity of .ar format would |
| 64 |
reduce the outer size of binary packages, I think the format is simply |
| 65 |
too obscure. It lives mostly as static library format, and the tooling |
| 66 |
for it is part of binutils. LSB considers it deprecated. While I don't |
| 67 |
see it going away anytime soon, I'd rather not rely on it in order to |
| 68 |
save a few KiB. |
| 69 |
|
| 70 |
|
| 71 |
Is there anything left to address? |
| 72 |
|
| 73 |
-- |
| 74 |
Best regards, |
| 75 |
Michał Górny |
Archives