> As for the obvious question, "Will this reduce my download time?",
> the above tool can't affect that. If memory serves, having a
> "linux...i386.tar.gz" was discussed at one point and (rightfully, IMO),
> shot down. Two tars and two patches for each kernel is plenty on
> ftp.kernel.org and mirrors... Those who find the download time too long
> can still patch up from a base kernel.
I agree that splitting the patches is bad; there should be one and
only one patch per kernel rev, to include patches for the entire
kernel. However, splitting the non-patch versions makes a certain
amount of sense, if done in moderation (as seen in numerous other large
packages like emacs, perl(?), ghostscript...); someone's mentioned an
enhanced patch-kernel that will even filter the patch so it applies
cleanly despite missing subtrees. Non-developers can get only what
they need, while developers can mget all the subtrees, so they can
at least look and see if their work impacts any subtrees they don't
use. To keep things in sync, all subtrees ought to share a common
numbering (as they already do); we might want to make LATEST-subdir
symlinks and not actually release new tarballs of unchanged subtrees
every version...
Keith (do mirroring programs grok symlinks?)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu