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

[Matthias Klumpp]

Am Do., 28. Jan. 2021 um 17:09 Uhr schrieb Jeremiah C. Foster
<jeremiah.foster at puri.sm>:
>
> On Thu, 2021-01-28 at 16:54 +0100, Matthias Klumpp wrote:
> > [...]
> > 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?

I just had to google that - this CycloneDX XML looks crazy similar to
AppStream XML ^^
The purpose of AppStream is to provide descriptions of individual
software components[1] that can be used to present software to the
user or allow automated systems to make decisions about these
components (like whether one is missing from a system and should be
installed, or whether one has security issues, ...).
Technically, any piece of software can have AppStream metadata, in
practice currently mostly desktop-applications have it in order to be
shown in software centers (but also fonts, icon-themes, console-apps,
Cockpit apps, ...).
I would love to use AppStream as a means to see what's inside
runtimes, e.g. Flatpak runtimes as well - but that would require a
huge effort to add metainfo files to everything, and just by seeing
which packages were used to build runtimes you can get most of the
interesting information already.

So *maybe* if everything had metainfo files AS could be used as SBOM,
but I honestly don't know enough about the requirements for the latter
to give any definitive answer to that. It certainly wasn't intended to
be one initially.

Cheers,
    Matthias

[1]: As opposed to complete projects, which can be described with DOAP

-- 
I welcome VSRE emails. See http://vsre.info/