On Fri, Mar 2, 2018 at 12:40 PM, Neal Gompa <ngompa13@xxxxxxxxx> wrote: > On Fri, Mar 2, 2018 at 12:35 PM, Nico Kadel-Garcia <nkadel@xxxxxxxxx> wrote: >> On Thu, Mar 1, 2018 at 9:46 AM, chicago <chicago@xxxxxxxxxx> wrote: >>> Good question. What is in this 20+58MB? Is it all text? Does most of it it change infrequently?/Maybe we can diff it? >> >> Most of it is pretty stable. But it's database-stored, and it's >> compressed. Both cause the overall files to change and be awkward to >> incrementally update, even if only one RPM actually changed. >> >> This is an old issue. One can reduce the download size needed and >> expand the local disk and computational requirements by adding >> delta-update and repodata merge tools, much as "deltarpms" did for the >> RPM's themselves. It helps, but it's also adding local CPU burden, and >> filesystem churn on the upstream repos to try and maintain that binary >> data as well as the original repodata. In My Honest Opinion, this is >> not going away until the whole "let's keep this all in one database" >> approach is discarded and individual small metadata files for each >> RPM, which can be surveyed and updated individually, replace the >> repodata. That is much more like apt, and it's unlikely in the >> foreseeable feature. > > APT hasn't done it this way in years. They've been actively reducing > the number of files because it makes it punishing for mirrors and is > rife for synchronization errors. I'm old. ;-) And... interesting. The trade-off between "I can incrementally update this by updating small files" versus I have an efficient but monolithic database and have to update that atomically" can be fun to select. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
