devsk wrote:I was talking about simpler stuff than people are talking about in those posts. For a package like gentoo-dev-sources and going from 2.6.0 to 2.6.1, why can't they keep just the patches tar (genpatches tar keeps tracks of patches for gentoo-dev-sources on top of development-sources, just keep adding one to that tar). ebuild for this patch checks if gentoo-dev-sources-2.6.0 is installed, it then just epatch'es all the patches in that tar, so existing sources get overwritten with the changes that were part of 2.6.0 -> 2.6.1 bringing my current source tree to latest. kernel.org releases patches on top of development-sources.
What you're proposing it a bit of a pita; to do it _correctly_, you need to determine what reference/base version exists, from there, verify the file is valid (md5 check). Determining a base and patches needed isn't too hard, I've already written out code that does that for my work w/ glep9. So, say 2.6.0 was determined as the base; for _strictly_ packages using genpatches, specifically using a common variable UNIPATCH_(DOC|LIST) we'll say, you'd have to either make the ebuild able to determine the base, and patch from there, or stick that functionality in an eclass.
That sounds nice and fuzzy, but has some rather annoying problems- untar the 2.6.0 kernel, it drops it's source in linux-2.6.0; now you have to make the ebuild use the old work dir (linux-2.6.0 rather then linux-2.6.1). That's extra cruft that needs to be jammed into an eclass/ebuilds.
Hokay lets just say that the issues above and a couple others I've left out for brevity have been dealt with- now there is the annoyance of having to repatch the kernel every single time w/ the 2.6.1 patch; minor, but such a setup gets old _quick_ when you get upto 2.6.5 and you have to apply the entire .1 -> .2 -> .3 -> .4 -> .5 set of patches.
To head off the 'why not just use a patch that goes from .1 directly to .5', jamming the logic to handle that into an eclass/ebuild is utterly problematic. To enable such behaviour, you need shortest path determination, which is not something you want to try in bash.
devsk wrote:It can reduce time to download for security fixes, reduce time for to configure and build the kernel again
Time to download for security fixes? It takes time for a security fix to be tested, then pushed into the tree; from there, there is the time involved in syncing, and building- you're worried about downloading? For a security fix, most of the time it's an additional patch, not the full src. Please elaborate- I might be missing what you're getting at w/ that statement.
devsk wrote:For all other packages in portage, this doesn't apply because source anyway is in a tar and your "diff" or "patch" based system has to be complex.
How does it not apply? The kernel is distributed in tar; the extra patches apply for the various kernel versions are non-vanilla tweaks, not version bumps. Fundamentally, patching the kernel src tarball is no different then patching any other src tarball.
Unless I'm missing something what you're getting at there.
Either way, basically either a lot of rather nasty work must be done for one particular set of ebuilds, or glep9 gets finished.
The general route imo is the better way; added the patch size to be pulled down is typically much smaller then pulling the diff patch (mentioned above in the binary differencer vs gnudiff discussions in threads listed above).
