[arch-general] [arch-dev-public] kernel 2.6.34-1

[C Anthony Risinger]

On Wed, May 19, 2010 at 9:43 AM, Jan de Groot <jan at jgc.homeip.net> 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 at archlinux.org> 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