On Mon, Sep 4, 2017 at 12:33 PM, Richard Hughes <hughsient@xxxxxxxxx> wrote: > On 4 September 2017 at 17:15, Dennis Gilmore <dennis@xxxxxxxx> 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! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
