I'm just putting this "out there", for some consideration and discussion. I'm hoping someone can come up with a better idea than I have and that perhaps there will be some kind of positive response to the request.<br>
<br>Here it is: whilst I totally appreciate all the hard work that goes into patching and maintaining the current release version of large packages (like the kernel, <a href="http://openoffice.org">openoffice.org</a>, or even just warsow, which has a large data component), I don't appreciate a 78mb download every other day because one config item in the kernel config has been changed or tweaked. I know there are people who are sitting with hardware doing odd things or the like, who need those patches, so I'm not expecting the development or release to cease or slow in anyway -- I'm just wondering if there isn't a better way to distribute the changes to the end user. <br>
<br>In particular, what comes to mind is how the modification of ONE kernel module requires the re-download of the kernel, headers and (if, like me, you have it installed) the kernel source package. Debian has an awesome packaging system which has allowed the segregation of larger packages into smaller, dependant ones so that changing something small doesn't have to cause a monstrous bandwidth load for the end-user. I know that a lot of people sitting on uncapped (or large-cap) broadband are thinking "who cares?" but there are a lot of people (especially in the country of origin for Ubuntu - South Africa - who get by on dial-up or a 1Gb capped "broadband" (because it's not broadband by the standards of the rest of the world) internet connection. Forcing a user like that to download 400-600mb over a 2 or three weeks really eats into their allotted bandwidth.<br>
<br>So, the simplest proposal is to split out the kernel package into smaller packages (much like XOrg, with the video drivers and other parts split out separately) so that, for instance, a bug fix for intel wireless doesn't have to cause a massive download for everyone, regardless of whether or not they have intel wireless; conversely, it means that fixes can be conveyed to the end-user as quickly as before (probably quicker, because of the smaller download!). Getting more complex, one could look into binary diffs between packages. But, using the existing architecture that is in place, simply breaking the kernel up into smaller pieces will definitely help. I remember a time when Debian had at least two packages for the kernel -- the image and the modules, and the modules were just a dep of the image, so first-timers got both. But updates to the image didn't require a re-download of the modules and vice-versa.<br>
<br>Thoughts, anyone?<br clear="all"><br>