2017-09-04 19:20 GMT+02:00 Richard Hughes <hughsient@xxxxxxxxx>: > On 4 September 2017 at 17:56, Neal Gompa <ngompa13@xxxxxxxxx> wrote: >> 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? > > 100% agree. This does take some time currently (as we have to > decompress some files from the lzma archives) but this is currently > done using my AMD Athlon Neo Microserver with spinning rust drives. > Using something XEONy and SSDy it'd be orders of magnitude faster. Are > we sure that we're using createrepo_c for composes? I know we *used* > to be the old python one for some reason. As I understand, the problem with the decompression is that it fetches the payload. And if a rpm weight 100MB, it will downloads (RPMs are often stored on nfs, so network is involved) and decompress the whole 100MB (including the header, although this last might be uncompressed). On the opposite, storing information on the RPM header means grabbing only the first KB out of the whole RPM. As one can see, this might work for few RPMs, but this doesn't scale at all on a big whole repository with many arches, specially if the work from a previous appdata-builder run cannot be cached for a later updates. So I wonder if it would be possible to have a "second payload" with only the appdata (xml, imgs) that it would be possible to fetch along the header without having to get the rest of the RPM ? On the second tough, with the effort needed to extract this information out of the rpm, is it really worth to store them there in the first step ? Over storing an URL (for xml and/or imgs) in the RPM header ? Thx for correcting me where I'm wrong. -- - Nicolas (kwizart) _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
