I'm looking at my machine slowly download all of evolution-1.2.3 in order to update evolution-1.2.2. Similar sort of issue if I update kernels. Since this is a source based distro, I think we would be able to save substantial bandwidth if portage realizes that it is just updating an existing source tree and just downloads the diff. Assuming people want to keep the old source tree .gz around just in case, portage can copy the old source tree to a new file, patch it up to the new version and compile.
most of the new ebuilds do this - based on this I would have to guess that there would be a reason why a new emerge actually fetches whole source file?. for example gentoo-sources/kernel-2.4.20 versions have linux-2.4.20 gentoo-sources-2.4.20-r1 - a patch. xfree-4.3.0-r1 does xfree-4.3.0 + drm-patch.
I beleive what the poster was meaning was a upsteam version change, not a gentoo reversion change. Like linux-2.4.19 to linux-2.4.20. Just dl the patch and patch it insead of dling the whole 2.4.20 tarball. The problem with this is the checksums portage does on tarballs. If you tar up the new patched kernel you're not garentieed to have the same md5sum.
Exactly. For example, if I want the kernel tree for 2.5.65-mm3, emerge will download the vanilla 2.5.65 kernel and it will download the mm3 patches, patch the vanilla source and I'm ready to go. But notice that it downloaded the entire 30 meg vanilla kernel. If I was already sitting on 2.5.64, why shouldn't it download just two sets of patches (2.5.64->2.5.65 and the mm3 patches). The download has just been reduced from roughly 31 megs to 2 megs.
The shear number of patches that would need to be distributed prohibits an all out patch distribution from ibilio (in my humble opinion at this time). Even just considering the number of patches that occur from version jumps in the same ebuild the number of permutations grows. Solution would be scripts on the mirrors. Does anybody know if mirrors would be willing to put scripts on their servers to provide this? Idealy the script would only generate the patch the first time it is requested and cached there after. This shouldn't be too much of a burden on a mirror cpu (priority nice setting would ensure this). I'm willing to do a best attempt at a server script and a portage patch to support this if some definate insight can be given to the one question raised here. I'm not too keen on downloading 200meg next time openoffice does a minor version release either.
duplicate of #11470
*** This bug has been marked as a duplicate of 11470 ***
