On Fri, Mar 2, 2018 at 12:40 PM, Neal Gompa <ngomp...@gmail.com> wrote:
> On Fri, Mar 2, 2018 at 12:35 PM, Nico Kadel-Garcia <nka...@gmail.com> wrote:
>> On Thu, Mar 1, 2018 at 9:46 AM, chicago <chic...@airmail.cc> 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 -- firstname.lastname@example.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org