HERE is more information about zsync. Basically it is a client-side rsync, which doesn’t make heavy load on the servers and you only need HTTP/1.1 Range support, which almost all servers support. Believe it or not some people are on meteres connections and to update each package with the full size each time, when there is a solution is not a good approach.
Is there something which prevents Canonical from adding zsync support to servers and to APT?
Can you please elaborate as to what you think is needed here?
We provide http, rsync, ftp access to Ubuntu Archive.
For cdimages we provide zsync files, which allow for incremental download and updates between iso images, thus uzing zsync files makes it quick to update iso images between daily builds.
I’m not sure there would be any gain in uzing zsync for the Ubuntu Archive itself. We store all metadata by-hash, thus each publication generates unique files. Release pool of files are all unique and don’t change. And debs in the -updates-/-security are also all unique. Thus there wouldn’t be much advantage between rsync & zsync for mirrorning ubuntu archive pool/ would there?
So there is NO way for updates to only download delta? There isn’t anything that can be done for this?
What is needed is ability for end customers to not download the full package including the unchanged files inside it when updating.
There is currently no support for that in Ubuntu afaik, it has been discussed in the past and the details of the work needed are written on https://wiki.ubuntu.com/UbuntuDebdeltaSupport but it’s stopped there
note that if you wanted something like rsync/zsync to be used, the transport protocol is the least of your problems.
to use either of these protocols you actually need a copy of each last version of the installed debs stored locally to sync against to actually benefit from the sync features.
so you’d need to teach the image build tools to keep a package pool iside the live session, apt to keep a pool after install etc etc … this will massively raise the minimal disk requirements and image sizes …
the alternative is to pre-generate deltas server side for each possible upgrade path like snap uses and to then simply download a binary delta blob …
both implementations are requiring a non-trivial amount of implementation work, it isnt “just add the transport” but a lot of infrastructure on both sides …
Hmm, i just noticed sudo apt autoclean. It cleans some locally stored .debs, can’t it be used?