Dne 5.9.2017 v 08:31 Nicolas Chauvet napsal(a): > 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. > Just another idea reading this ... could we move the AppStream data into subpackage? Vít _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
