On Mon, Sep 4, 2017 at 4:02 PM, Dennis Gilmore <dennis@xxxxxxxx> wrote: > 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. > Wait, what? Is this because of mash? That should go away with Bodhi moving to pungi, right? As for avoiding the rpm payload, I don't think you're going to find a workable solution. Pretty much all distributions supporting AppStream metadata are doing it this way. The appstream-generator tool (used by the Debian and Arch guys) peeks into deb/archpkg files and grabs the data out too. Richard's appstream-builder follows the same strategy. The only possible approach you might find palatable is SUSE's... SUSE's method of dealing with AppStream data is to have a brp script (brp-extract-appdata) that extracts the information during package build time. The build service then processes that extracted metadata and creates the correct appstream repodata and appends it to the rpm-md repodata. That could work for us, but it'd require work to dist-repos and pungi and bodhi so that the extracted appstream content is merged together to create the repodata and properly appended. SUSE's approach also works rather well because the OBS is aware of the distribution dependencies and automatically handles ensuring the consistency is there. It's pretty much Koji + Koschei + COPR+ releng mass rebuild scripts + pungi + bodhi in one system. No split brains means consistency is easy to guarantee. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
