Neal Gompa writes:
On Mon, Dec 21, 2020 at 1:14 PM Marius Schwarz
<fedoradev(a)cloud-foo.de>
wrote:
>
> If something really needs to change, it is the 50+ MB repo database that
> gets downloaded. It takes ages on slow connections to download
> and than you want to increase the size of the rpms too.. Doesn't sound
> like a good idea.
>
You should be getting delta fetching of repository metadata with
zchunk metadata, which we've had enabled since Fedora 30:
https://fedoraproject.org/wiki/Changes/Zchunk_Metadata
Is this not working for you or something?
Well, I don't know what's working for me, or not working for me. All I know
is that:
1) I'm rsyncing the updates repo to my LAN, and other machines in my lan
have the default updates repo disablde and a replacement repo pointing at my
local copy.
2) Even on the LAN, an update downloads something from the local repo,
giving me a zippy progress indication of the download. After the download it
sits for a noticeable amount of time before it decides exactly what it's
going to update and then gives me the list. This is especially noticable for
a Fedora VM guest that I'm running in a VM that's emulating an aarch64
platform. In the emulated aarch64 VM downloading of RPMs goes a bit slow,
but the subsequent pause after download is quite noticable.
Except for rsyncing a mirror of the updates repo locally and then pointing
everyone to my local mirror, I am not doing any other customization and
that's the behavior I've seen.
Having said all that, I don't find the update process to be that much of a
pain point right now, and in any dire need of improvement. It works. It is
fairly reliable. A bit slow, but who cares. The important thing is that
except for a burst of segfaults downloading rpms earlier this year (haven't
had any in a while) it's been rock stable and hiccups are very, very rare. I
don't exactly see what's the big value-added from the described feature
enhancement, I'd only want to make sure it's just as stable.