On Mon, Sep 4, 2017 at 3:57 PM, Dennis Gilmore <dennis@xxxxxxxx> wrote: > El lun, 04-09-2017 a las 17:33 +0100, Richard Hughes escribió: >> 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: > We have had this discussion about 3 or 4 times. > >> * What happens if a single package contains two desktop files? > both end up in the headers, >> * Would we embed a 32bit color 128x128 icon in the rpm header (10kb >> per app)? > we would have to, there is simply no sane way to extract and manage > things from inside the rpms. the appdata being agnostic is great, but > there has to be a technology specific way to manage the data without > expensive overhead > >> * 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. > > we would have a end user gain, they would get consistent updated > correct data all the time. > We could do that *now*. Other distributions (openSUSE, Mageia, Debian, etc.) generate the metadata and append it to the repodata, so that it *is* consistent since it was made along with the regular metadata. It would probably be somewhat faster with createrepo_c itself supporting it, but it's not mandatory. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
