Re: [RFC] gpkg format proposal v2 (was: Re: [gentoo-portage-dev] [RFC] Improving Gentoo package format)

[Michał Górny]

On Tue, 2018-11-13 at 10:03 -0800, Zac Medico wrote:
> On 11/13/18 9:53 AM, Zac Medico wrote:
> > On 11/13/18 9:49 AM, Zac Medico wrote:
> > > On 11/11/18 12:53 PM, Michał Górny wrote:
> > > > Hi,
> > > >
> > > > Ok, here's the second version integrating the feedback received.
> > > > The format is much simpler, based on nested tarballs inspired by Debian.
> > > >
> > > > The outer tarball is uncompressed and uses '.gpkg.tar' suffix.  It
> > > > contains (preferably in order but PM should also handle packages with
> > > > mismatched order):
> > > >
> > > > 1. Optional (but recommended) "gpkg: ${PF}" package label that can be
> > > > used to quickly distinguish Gentoo binpkgs from regular tarballs
> > > > (for file(1)).
> > > >
> > > > 2. "metadata.tar${comp}" tarball containing binary package metadata
> > > > as files.
> > > >
> > > > 3. Optional "metadata.tar${comp}.sig" containing detached signature
> > > > for the metadata archive.
> > > >
> > > > 4. "contents.tar${comp}" tarball containing files to be installed.
> > > >
> > > > 5. Optional "contents.tar${comp}.sig" containing detached signature for
> > > > the contents archive.
> > >
> > > We'll want to access "contents.tar${comp}.sig" very early, but in the
> > > absence of an index containing offsets, normally we'd have to read all
> > > of "contents.tar${comp}" first. However, I suppose we could search
> > > backwards for the "contents.tar${comp}.sig" entry.
> >
> > We could solve this problem by adding an index file containing offsets
> > as the last file in the outer tar file.
>
> Actually, the tar entry for "contents.tar${comp}" should contain the
> length, so we should be able to efficiently seek to the
> "contents.tar${comp}.sig" entry. So, an index is not really needed.

Precisely.  Tar is pretty much a linked-list, so seeking is quite
efficient, as long as it's not compressed.

-- 
Best regards,
Michał Górny