Mailing List Archive

>>>>> On Thu, 23 Sep 2021, Sheng Yu wrote:

> Hi,
> I attached second revision of the new draft of GLEP78 "Gentoo Binary
> Package Container Format"

> Please feel free to give any comments and suggestions.

Since you haven't addressed my comments from the first round of review,
I repeat them here:

| Given that the outer archive is uncompressed tar, every file will be
| zero-padded to a full block which adds some amount of bloat. So, could
| the signature be inlined in the Manifest file? That's also what GLEP 74
| specifies.
|
| Also, IIRC one of the goals of the format was to allow partial download
| of metadata. That will only work if the Manifest file will be the first
| file in the archive (or at least appear before the image archive).

Ulrich

Hi Ulrich,

Sorry, I don't know why the response I sent on September 13 didn't get
forward by mailing list. So I write here again.

??????? Original Message ???????

On Thursday, September 23rd, 2021 at 06:30, Ulrich Mueller <ulm@gentoo.org> wrote:

> Since you haven't addressed my comments from the first round of review,
> I repeat them here:
>
> | Given that the outer archive is uncompressed tar, every file will be
> | zero-padded to a full block which adds some amount of bloat. So, could
> | the signature be inlined in the Manifest file? That's also what GLEP 74
> | specifies.

Using inline signature makes sense but leads to another problem: we allowed
user-defined GPG commands, which gives us no control over exactly what
format is generated, and how to verify it. And I do not feel hard coded
"--clear-sign" and "--detach-sign" to the commands are good practices.

Also this is a very limited space saver, probably only max 1kb per package.

This specification only using the Manifest DATA tag format in GLEP 74:
DATA <path> <size> <checksums>...
and their definition. So the inlined signature is not applied here.


> |
> | Also, IIRC one of the goals of the format was to allow partial download
> | of metadata. That will only work if the Manifest file will be the first
> | file in the archive (or at least appear before the image archive).

The metadata signature is strictly requested to be the next file after the
metadata archive, so it can be used to verify metadata without need Manifest.
Although the specification said that non-standard order should be supported,
but this does not apply to remote fetches.

The biggest problem with moving the Manifest to the head is how to write it.
Since this file can only be created after all other operations have been
completed.

To do this, we either have to store other files in the temporary area and
copy them into binary package when the Manifest is created, and double the
free space requirement. (especially for those who use tmpfs to get faster IO).
Or reserve space in the binary package container and overwriting it later.
But since both Manifest and signature size are variable, how much space to
reserve becomes an issue. Too small, the package manager needs to copy the
whole package, too big will require adding a padding file.


Thanks,
Sheng Yu