I’m not sure, maybe it is already done this way, but not sure. When dnf fetches info about available updates it could be done in following way:
- Upgraded system holds info about last package timestamp update it already have fetched
- It ask Fedora to get updates only from this timestamp (it sends http request with parameter of last timestamp)
- It gets response only with updated packages occured since timestamp
- RPM transaction starts
- System merges updates list to database
- System updates last timestamp updated
7.RPM transaction is commited
There’re timer services for both DNF and PackageKit updating indexes on schedule.
Then it compares the versions of the installed packages with the available ones.
If it finds newer available versions, then the update notification/action can be issued.
So, we have the following databases:
- Installed packages - managed by RPM.
- Available packages - managed by DNF and PackageKit.
- Transaction history - managed by DNF.
In addition, available packages use separate databases:
- Separate databases for DNF and PackageKit.
- Separate DNF databases for each user.
I do not know if I understanding You correctly.
What I mean is communication is transfer between Fedora Repository and computer on which Fedora is installed. I observe some relatively big fetches (tens of MB). From my understanding my computer fetches new packages as file.
What could be done is to have some script on Fedora Repository which creates update result depending on what client has already fetched. E.g if only three packages changed since last query it will send only this three packages info updates. I mean sync repository info about packages, not updating packages.
Maybe it is too complicated to maintain repository mirrors, because this scripts would need to be installed on mirror servers.
It’s probably PackageKit automatically pre-downloads updates for offline installation.
You can disable automatic updates, or remove GNOME Software together with PackageKit.
However, I’m afraid that changing the update protocol is problematic.