| 1 |
On Mon, Sep 13, 2021 at 5:02 PM Michał Górny <mgorny@g.o> wrote: |
| 2 |
> |
| 3 |
> On Mon, 2021-09-13 at 12:08 +0200, Ulrich Mueller wrote: |
| 4 |
> > |
| 5 |
> > Also, IIRC one of the goals of the format was to allow partial |
| 6 |
> > download |
| 7 |
> > of metadata. That will only work if the Manifest file will be the |
| 8 |
> > first |
| 9 |
> > file in the archive (or at least appear before the image archive). |
| 10 |
> |
| 11 |
> I disagree. This is solved by having detached metadata signature -- you |
| 12 |
> can do a partial fetch and verify the metadata directly. |
| 13 |
> |
| 14 |
|
| 15 |
Another option I've tossed out there in the past is having a content |
| 16 |
hash of the metadata and putting that in the filename. That obviously |
| 17 |
won't tell you anything about the contents of the file without reading |
| 18 |
it, but if you're looking for a file with specific metadata you could |
| 19 |
predict its filename. This was intended to work with having multiple |
| 20 |
hashes for the same file using subsets of the metadata, using symbolic |
| 21 |
links. |
| 22 |
|
| 23 |
The thinking here is that you'd just hash a subset of metadata useful |
| 24 |
for identifying what file you'd want to download, such as CHOST, |
| 25 |
linked dependency versions, use flags, etc. You'd probably hash it |
| 26 |
with/without stuff like use flags so that you could either take a shot |
| 27 |
at getting the file exactly configured how you want, or accepting a |
| 28 |
version with any set of flags. |
| 29 |
|
| 30 |
Of course, this idea goes in direct opposition to your statement about |
| 31 |
not wanting to specify the filename. I get that argument. The intent |
| 32 |
here was to allow portage to go hunting through trusted repositories |
| 33 |
to find packages it can use without having to sync a lot of data - if |
| 34 |
you know the exact filename then a simple GET tells you if it is there |
| 35 |
or not. |
| 36 |
|
| 37 |
-- |
| 38 |
Rich |
Archives