El lun, 04-09-2017 a las 17:33 +0100, Richard Hughes escribió:
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:
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.
Dennis