[AppStream] Adding <filename> to <artifact>?

[Jeremiah C. Foster]

On Thu, 2021-01-28 at 16:54 +0100, Matthias Klumpp wrote:
> 
> Am Do., 28. Jan. 2021 um 15:27 Uhr schrieb Richard Hughes < 
> hughsient at gmail.com>:
> > 
> > Hi all,
> > 
> > I've just switched the LVFS from the nonstandard:
> > 
> >       <release version="1.2.5">

[snip]

> > This is pretty complete; although missing one bit of data. When we
> > use
> > the <location> with <artifact> we don't actually now know the
> > filename
> > to use for the download or disk cache -- which I snuck into the
> > <checksum> before. What about something like
> > <filename>9a4e77009da7d3b5f15a1388afeb9e5d41a5a8ae-hughski-
> > colorhug2-1.2.5.cab</filename>
> > as a child of the <artifact> element?
> 
> Two questions: Why do you need a filename at all for a cache?
> Wouldn't
> just using any of the checksums be enough?
> And second: Why does the filename contain something like a hash
> already? Shouldn't it be
> <filename>hughski-colorhug2-1.2.5.cab</filename> with any "make it
> unique" hashes appended by the caching code on the client side,
> rather
> than trusting a value in the metainfo file?

+1 (To both questions.) I feel it is a little DRYer to just have a file
name without a hash. 

Also, AppStream feels like a streamed "Software Bill of Materials"
(SBOM). Have we looked at the SBOM work being done at all? Or is that
irrelevant bloat?


Cheers,

Jeremiah
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/appstream/attachments/20210128/0678de99/attachment.sig>