[Bug 491090] Review Request: kernel-firmware - firmware files for use with Linux kernel

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=491090


Nicolas Chauvet (kwizart) <kwizart at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|nobody at fedoraproject.org    |kwizart at gmail.com




--- Comment #3 from Nicolas Chauvet (kwizart) <kwizart at gmail.com>  2009-04-06 09:14:42 EDT ---
I can review the package itself , but I can expect few problems.

While it is definitely better to find firmwares in one place over the web, it
is also enhancement to remove various firmwares from the source kernel and then
the kernel.src.rpm . I expect having a monolithic kernel-firmware package to
lead to various problems. I will try to sort the issues I expect here, but I
won't prevent this package to be introduced. So I'm starting the review.

1 - I cannot identify which driver(and license) is related to this file:
* atmsar11.fw ?

2 - Some firmware that was previously removed (seen in alsa-firmware or other
packages) still appear within WHENCE - minor.

3 -  Potential Conflicting files:
* Found in alsa-firmware-1.19
File: ess/maestro3_assp_kernel.fw
File: ess/maestro3_assp_minisrc.fw
* Found in libertas-usb8388-firmware
/lib/firmware/usb8388.bin (not exactly the same namespace than kernel-firmware
libertas sub-directory)

4 - kernel-firmware size.
The kernel-firmware size will grow from a ratio of 10 with new kernel-firmware
introduction (320ko -> 3.2Mo) . This lead to two questions.
- Are some firmwares bundled in kernel-firmware supposed to be updated?
This might not be relevant as soon as we are using presto. But it seems safer
to only bundle firmwares files that doesn't move often.
- Is it possible for big firmwares image to be splited to another package so
they can be un-installed easily.
This is very important for LiveCD folk to have a image <700Mo if some old/rare
firmwares can be removed.
- Do every drivers related to each firmware files are relevant on every CPU ?
(x86, x86_64, ppc, ppc64). I expect some are only x86 and x86_64.
(minor).

5 - kernel-firmware version. 
Using a date will allow kernel-firmware to update the one built from the
kernel.src.rpm. But it isn't clear what this date means. For example we don't
know if the last collection to date is also suitable for 2.6.27 kernel or
2.6.30. 
One could say it is the last archive that have a firmware update. or the
archive that collected others firmwares (even if those firmwares was older than
the written date).
So keeping the kernel version may eventually suggest that a minimal kernel
version is needed with this firmware collection. (like 2.6.27.$date-)

6 - Multiple ABI for firmware. 
To assure smooth transition, we used to eventually bundle multiple ABI of a
firmware (seen in iwl4965-firmware) The request from rel-eng was that the same
package should allow to work on kernel from F-n to F-n+2. Hence, this kind of
Upgrade can allow a fallback if something went wrong.
If a firmware can use different ABI. It would be more relevant to split it in
another package.

7 - kernel-firmware and kernel interaction.
Since kernel-firmware can be optional. It will be better not to have a
Requires: kernel-firmware >= kf-version but a conflict: kernel-firmware <
kf-version from the kernel itself. Once that said, each driver could requires a
different kernel-firmware version if multiple ABI can be bundled for a given
driver.

8 - Building subpackage vs splitting tarball for kernel-firmware.
It might be easier at the first sight to build sub-packages if more splitting
is needed. (for big firmware). One can say it will not matter since we have
presto enabled by F-11. The problem is with sorting the required version for
earch firmware and the kernel cannot be solved by splitting sub-package.

9 - kernel-firmware to be a default/optional package ?
Since this package bundles various kind of firmwares, it would depends on the
case to know if this would be better to have it installed by default or
optional.
I think it is better to have raid disk, nic adapter and wifi, installed in the
default install media while v4l devices can be installed in post install. Other
adaptation could be done if the device remains rare or for the LiveMedia case.


Actually, there is only one thing that could prevent this package to be
introduced in Fedora, it is the unknown redistribution status of some
firmwares.
We may implicitly consider that if firmwares was contributed to the kernel, it
is allowed to redistribute. Do we have a FE-legal advice about that?


So, to sum up the package review itself. I would have a general answear on the
point I have raised. 
It will also be better to fix conflicting files along with thinking of a better
version scheme that may prevent epoch uses before to introduce the package.
* There is a typo in the URL : htp://
* rpmint warning on kernel-firmware.src: 
 W: mixed-use-of-spaces-and-tabs (spaces: line 7, tab: line 1)
* Some licenses are bundled in the sub-directory whereas only License.* and
WHENCE are bundled as %doc.

Thoses items was checked and are OK:
- Timestamps have been keept while installing files.
- Every docs/Licenses are either ASCII or UTF-8

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.