On Monday, September 13th, 2021 at 18:04, Rich Freeman <[email protected]> wrote:
>
> On Mon, Sep 13, 2021 at 5:02 PM Michał Górny <[email protected]> wrote:
> >
> > On Mon, 2021-09-13 at 12:08 +0200, Ulrich Mueller wrote:
> > >
> > > 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).
> >
> > I disagree.  This is solved by having detached metadata signature -- you
> > can do a partial fetch and verify the metadata directly.
> >
>
> Another option I've tossed out there in the past is having a content
> hash of the metadata and putting that in the filename.  That obviously
> won't tell you anything about the contents of the file without reading
> it, but if you're looking for a file with specific metadata you could
> predict its filename.  This was intended to work with having multiple
> hashes for the same file using subsets of the metadata, using symbolic
> links.
>
> The thinking here is that you'd just hash a subset of metadata useful
> for identifying what file you'd want to download, such as CHOST,
> linked dependency versions, use flags, etc.  You'd probably hash it
> with/without stuff like use flags so that you could either take a shot
> at getting the file exactly configured how you want, or accepting a
> version with any set of flags.
>
> Of course, this idea goes in direct opposition to your statement about
> not wanting to specify the filename.  I get that argument.  The intent
> here was to allow portage to go hunting through trusted repositories
> to find packages it can use without having to sync a lot of data - if
> you know the exact filename then a simple GET tells you if it is there
> or not.

Interesting concept, although this should be counted in the
binpkg-multi-instance. A predictable configuration hash, rather than
relying on index to get the difference between variants.

Something like:
bar/foo-1.0-r2-e3b0c44298fc1c149afbf4c8996fb9.gpkg.tar

Thanks,
Sheng Yu


Reply via email to