Redownloading huge sources when one already has a previous version sitting in /usr/portage/distfiles is a serious waste of bandwidth and time. The inverse of this is also friendly to low bandwidth users. There are PLENTY of distfiles that are well over 10 megs, do a ls -l /usr/portage/distfiles/ | sort -k 5 -t ' ' to see some (they are at bottom) Sizes of gcc releases and patches attached (txt) Example gcc ebuild attached. you must ebuild attached.ebuild digest to get it going using autopatch USE flag Notes, problems needing addressed by portage and possible new functionality to make things seamless and smooth: Shipping large patches like these in portage's package/files directory will add unnecissary bloat and bandwidth usage while emerge rsyncing. So the patch is optionally downloaded (with use of new USE flag: autopatch - which should maybe be made default) ONLY if there is a previous version of package in distfiles AND the distfile of said ebuild isn't already there. Added benifit is that other non trivial patches can be moved to distfiles (where I think they should be anyway). This causes a few problems with digests however: portage as is, only lets the digest file hold one digest entry at a time, thus ebuild attached.ebuild digest replaces the digest. Also, there is no way to check the digest of a previous version from the ebuild. The attached is only an example (works after generating new digest btw) but demonstrates how easy it can be to do this. (diff against original to see what's different, not much!) Things that could make things even easier: Move a bunch of functionality into eclasses --- Release histories e.g. for gcc RH="3.0 3.0.1 3.0.2 3.0.3 3.0.4 3.1 3.1.1 3.2 3.2.1" This way, if I had, oh, say, gcc-3.0.3.tar.bz2 in my distfiles, I can patch all the way up to 3.2.1 (yes, this is STILL less then downloading 3.2.1 by itself) --- repack (optionally?) patched up source to current version and stick in distfiles, really though, patching is pretty quick. To do this, new digests would have to be created (and not clobbered during rsync) by portage. Well, that's about all I can think of for now. I would volunteer to do this, but I don't know a lick of python (c/c++/bash, yes) or am I familiar with the internals of portage to implement any of this in any timely fasion, however, I don't think it would be especially difficult for one to impliment with such familiarity.
Created attachment 6126 [details] gcc release and patch sizes
Created attachment 6127 [details] gcc-3.2.1.ebuild
*** Bug 13980 has been marked as a duplicate of this bug. ***
*** Bug 15928 has been marked as a duplicate of this bug. ***
The logic for this isn't particularly trivial. And creating digests isn't exactly short of complicated. Submissions of python code to do this are welcome...
*** Bug 17984 has been marked as a duplicate of this bug. ***
also have a look at bug #18354
teh deltup package from bug 18354 is in portage, and would solve this beautifully *** This bug has been marked as a duplicate of 18354 ***
