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@xxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|nobody@xxxxxxxxxxxxxxxxx |kwizart@xxxxxxxxx --- Comment #3 from Nicolas Chauvet (kwizart) <kwizart@xxxxxxxxx> 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review