-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Tue, 2017-09-05 at 08:37 +0200, Vít Ondruch wrote: > > 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? It is possible and probably even possible to add something like Provides: metainfo-handler() in appstream consumers (e.g. gnome- software) and automatically generate Recommends: (foo-metainfo if metainfo-handler()).. But I'm not sure if * it's worth it * we can add such things with current RPM (because it involves lookup of subpackage which IIRC is possible only to do in RPM code itself now) And as usual, before trying to do something "new" we should really look how our friends are solving such issues (e.g. openSUSE). Unfortunately we do a lot of things without doing so and then end up in bad situations. > > Vít > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx - -- - -Igor Gnatenko -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmuWsMACgkQaVcUvRu8 X0w6KxAAiOVFG7f91m+sOPJFkRlmx3Minlv1QJobxymv0bdDVDnAdbrBaTGbvY4b GL8D6FocqSMDUBwMxS/2gM2gstEVis5Ho0g2rLcde/fbDBhG4XKd2kdCm2egqMOd g/PFpCxmG9csrI040EaZ7bRYLeeClJPNyC99W3BTN2NOFbTH5/+Y86fu2wLTzuJI rMw1AiSWQLRzwcDvGoK7c5qOOsHiykLYDUGF68hBB2SvQKWqiIBKuOgxJ5v44X1I sMDo6QZq1h0kaYl3ezyXZ9Ssu7QrOfYxmQk+XPF29zz2PY0hyblmUIht536W5JLZ Km3J3N3ksQlP4GVh8WMRUTOiLnT2fYznD4IWhJqPlFcNavwSCebMq+g4VvT8JHPC A13OhbkbEVvDIO/WupiI+/sNmfjLAL4MzrVZS/lV0BNiwHdQis5+tsrJHLm02O/4 ytf8Jw9NzL99GGpaK9TaqxHs2KIyTNTTE1c2bglWyuf7JHuwNNgcOKlTL20gRiJe qcxs3KqhO2zniWLpxnA0zJPzavV8E+mBkB4ODqYUlPgCJy10jrVAJcrpqJreCUBG zrhWncmLxqDfsKCQsbtG4ZmTw/dtvhu+82BTWFCnWxJ/mVcCYyYWQwG403MqMdB7 yV9WgqSDBtoHZsJZvW2UPgm2mfGV+4ATYHICmBnvPYI08cnAvnw= =Yy6i -----END PGP SIGNATURE----- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
