On Wed, May 19, 2010 at 9:43 AM, Jan de Groot <jan@xxxxxxxxxxxxxx> wrote: > On Wed, 2010-05-19 at 16:39 +0200, Thomas Bächler wrote: >> Am 19.05.2010 16:19, schrieb Dan McGee: >> > On Wed, May 19, 2010 at 6:10 AM, Thomas Bächler <thomas@xxxxxxxxxxxxx> wrote: >> >> Am 19.05.2010 10:56, schrieb Evangelos Foutras: >> >>> Also did a diff [1] between the file lists of kernel26-firmware-2.6.34-1 >> >>> and linux-firmware-git-20100519-1. It shows that ralink firmware has >> >>> indeed been added to the linux-firmware repository, which should resolve >> >>> FS#19519 [2]. >> >> >> >> I did that too and noticed the same. It would also replace all intel >> >> ucode packages, and some more I don't know about. However, it is >> >> considerably bigger than kernel26-firmware (2MB vs. 12MB). >> > >> > How often does it need to be updated? We now (needlessly?) have the >> > firmware package track the actual kernel package so it ends up getting >> > re-downloaded a lot more often than probably necessary, so the above >> > package, while large, would probably be updated less anyway (and would >> > be an 'any' package?). >> >> Everytime someone complains about a firmware file missing. >> >> Seriously, look at the commit log, it only had 23 commits this year: >> http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=summary >> >> I guess we would upgrade it at most once a month. > > +1 for replacing all firmware packages included in this one. I don't > care about the few extra megabytes on my system. This saves us uploading > and downloading a binary firmware package on every kernel update, > generates less packages in the repositories and moves kernel26-firmware > to an arch=any package. The only disadvantage is the 10MB extra size, > but the advantages are bigger than that. yes i agree too. kernel is big already with oodles of modules enabled by default to satisfy everyone, whats a few more MB to ensure that things like KMS (nearly commonplace) and friends work smoothly. there isn't a simple way (or reason) to needlessly break them [firmware] out into individual packages, as there isn't a way to effectively depend on the package (would have to start breaking out modules themselves into packages, no?, in order to build the dep tree?) C Anthony
