El lun, 04-09-2017 a las 12:56 -0400, Neal Gompa escribió: > 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. 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. we currently use createrepo_c for GA releases and the old createrepo for updates. There has to be a way to easily extract the data without having to reach into the belly of the rpm payload. The soultion we use needs to work for anyone making repos and not be tied in anyway to a specific implementation of how we build ship and manage the software lifecycle. Dennis _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
