On Mon, Sep 4, 2017 at 12:33 PM, Richard Hughes <hughsient(a)gmail.com> wrote:
On 4 September 2017 at 17:15, Dennis Gilmore <dennis(a)ausil.us>
wrote:
> The correct way to deal with appstream is to add the appstream data to
> rpm headers and then teach createrepo to make the appropriate metadata
> files.
I'm sure we've had this discussion before, but:
* What happens if a single package contains two desktop files?
* Would we embed a 32bit color 128x128 icon in the rpm header (10kb per app)?
* Would we embed all the translations in the appdata file, or just the
entire appdata file (92kb per app)?
* Would we include the entire .desktop file and all the translations there too?
> you would then have appropriate appdata in the server,
> workstation etc repos
We'd have larger rpms for no end-user gain. The metadata just has to
exist long enough to be collected into one large AppStream file (and
included in the metadata repomd. I see no gain whatsoever for
distributing the single-package appstream metadata as part of the
package download or included in the rpmdb. It's just a workaround,
just the same as running appstream-builder+modifyrepo on a tree of
built rpms is.
It sounds like it would make more sense for createrepo_c to link to
the AppStream builder library to handle AppStream metadata processing
as part of the createrepo_c repodata generation, wouldn't it? Then it
accomplishes the same goal without bloating the rpm headers with more
things that don't make sense in there.
--
真実はいつも一つ!/ Always, there's only one truth!