The idea of package deltas just won't go away... However, binary diffs really are not ideal with pacman verifying the compressed package - that means we need to reconstruct the package on the users system to verify. Also our old approach using xdelta3 somewhat died when moving packages away from gz (or xz?) compression. Other binary diff approaches really suffered the same issue. In general, I find the approach of reconstructing the full package to be suboptimal. I also don't particulaly want to verify uncompressed packages. I wondered if this was a case of perfect being the enemy of good, so I have investigated a different, very lazy approach. Instead of taking a binary diff, we could just provide the files that have changed between package versions. This is super easy to do as we have checksums for all files in the mtree file. We could then extract this "diff" package directly, and use the mtree file to adjust timestamps/permissions/etc(?) on kept files, and it would be just like the full package had been installed. I ran some numbers to see if this was worth while. The results for the last bunch of updates for bash, coreutils, qt5-base and systemd are given here: https://wiki.archlinux.org/title/User:Allan/Pkgdiff On major version updates, this is approach is a waste of time. But for minor updates bash download would average 25% of the size, coreutils about 36% (though was ~1% for simple rebuilds!), qt5-base about 40% and systemd 60%. Not shown but worth noting note that when Arch changes gcc/binutils versions or updates CFLAGS etc, this can stop any binary diff being as useful. If we implemented using these diffs but only allowed it for updates from the previous package version (i.e. no diffs to package (current - 2) or earlier, or diff chaining), then this would be rather simple to implement (at least from the pacman side...). Any comments before I invest time implementing? Allan