Dne 4.9.2017 v 22:02 Dennis Gilmore napsal(a): > El lun, 04-09-2017 a las 12:56 -0400, Neal Gompa escribió: >> On Mon, Sep 4, 2017 at 12:33 PM, Richard Hughes <hughsi...@gmail.com> >> wrote: >>> On 4 September 2017 at 17:15, Dennis Gilmore <den...@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. > It would not be a good way to do things, the expensive bit is extacting > and manageing the appdata info. that is super expensive and comes with > other costs.
Could you elaborate what is super expensive on this? All the rpms which contains appstream data have metainfo() virtual provides, so they can be easily discovered. Later this is just about extracting the appropriate files from that RPMs. It doesn't look that super expensive .... V. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
