This doesn’t work too well for rolling releases, because users will quickly get several version jumps behind.
For example, let’s say libbanana is currently at version 1.2.1, but then releases 1.2.2, which you ship as a distro right away, but then a few days later, they’ve already released 1.2.3, which you ship, too.
Now Agnes comes home at the weekend and runs package updates on her system, which is still on libbanana v1.2.1. At that point, she would need the diffs 1.2.1→1.2.2 and then 1.2.2→1.2.3 separately, which may have overlaps in which files changed.
In principle, you could additionally provide the diff 1.2.1→1.2.3, but if Greg updates only every other weekend, and libbanana celebrates the 1.3.0 release by then, then you will also need the diffs 1.2.1→1.3.0, 1.2.2→1.3.0 and 1.2.3→1.3.0. So, this strategy quickly explodes with the number of different diffs you might need.
At that point, just not bothering with diffs and making users always download the new package version in full is generally preferred.
Hmm, good question. I know of one such implementation, which is Delta RPM, which works the way I described it.
But I’m not sure, if they just designed it to fit into the current architecture, where all their mirrors and such were set up to deal with package files.
I could imagine that doing it rsync-style would be really terrible for server load, since you can’t really cache things at that point…
This doesn’t work too well for rolling releases, because users will quickly get several version jumps behind.
For example, let’s say libbanana is currently at version 1.2.1, but then releases 1.2.2, which you ship as a distro right away, but then a few days later, they’ve already released 1.2.3, which you ship, too.
Now Agnes comes home at the weekend and runs package updates on her system, which is still on libbanana v1.2.1. At that point, she would need the diffs 1.2.1→1.2.2 and then 1.2.2→1.2.3 separately, which may have overlaps in which files changed.
In principle, you could additionally provide the diff 1.2.1→1.2.3, but if Greg updates only every other weekend, and libbanana celebrates the 1.3.0 release by then, then you will also need the diffs 1.2.1→1.3.0, 1.2.2→1.3.0 and 1.2.3→1.3.0. So, this strategy quickly explodes with the number of different diffs you might need.
At that point, just not bothering with diffs and making users always download the new package version in full is generally preferred.
Interesting, it wouldn’t work like rsync where it compares the new files to the old ones and transfers the parts that have changed?
Hmm, good question. I know of one such implementation, which is Delta RPM, which works the way I described it.
But I’m not sure, if they just designed it to fit into the current architecture, where all their mirrors and such were set up to deal with package files.
I could imagine that doing it rsync-style would be really terrible for server load, since you can’t really cache things at that point…
Yeah I guess these days the majority of users have fast enough connections that its not worth it. It sucks if you have crappy internet though hah.