does adding 

%define with_firmware 0

to the %ifarch s390x section around line 300 in the specfile
do the right thing?

rpmbuild of kernel doesn't produce a kernel-firmware package on _any_ architecture. The kernel-firmware package is noarch.

oh, yeah. hmm.

we could make the Requires: dependant on %ifnarch s390x maybe.

given the absence of PCI/USB on s390's I doubt there's anything useful in the firmware rpm at all on that arch.

That would be possible. But why bother with a special case?

%define kernel_prereq  ... kernel-firmware >= %{rpmversion}-%{pkg_release}

With that line in the spec, wouldn't all arches depend on kernel-firmware?  I think we need a special case here.

completely untested, but something like ..

--- F-10/kernel.spec~	2008-11-12 14:07:13.000000000 -0500
+++ F-10/kernel.spec	2008-11-12 14:09:58.000000000 -0500
@@ -422,7 +422,10 @@ Summary: The Linux kernel
 # Packages that need to be installed before the kernel is, because the %post
 # scripts use them.
 #
-%define kernel_prereq  fileutils, module-init-tools, initscripts >= 8.11.1-1, mkinitrd >= 6.0.61-1, kernel-firmware >= %{rpmversion}-%{pkg_release}
+%define kernel_prereq  fileutils, module-init-tools, initscripts >= 8.11.1-1, mkinitrd >= 6.0.61-1
+%ifnarch s390x
+%define kernelfw_prereq kernel-firmware >= %{rpmversion}-%{pkg_release}
+%endif
 
 #
 # This macro does requires, provides, conflicts, obsoletes for a kernel package.
@@ -437,7 +440,7 @@ Provides: kernel-drm = 4.3.0\
 Provides: kernel-drm-nouveau = 11\
 Provides: kernel-modeset = 1\
 Provides: kernel-uname-r = %{KVERREL}%{?1:.%{1}}\
-Requires(pre): %{kernel_prereq}\
+Requires(pre): %{kernel_prereq} %{kernelfw_prereq}\
 Conflicts: %{kernel_dot_org_conflicts}\
 Conflicts: %{package_conflicts}\
 %{expand:%%{?kernel%{?1:_%{1}}_conflicts:Conflicts: %%{kernel%{?1:_%{1}}_conflicts}}}\

might do the trick.

That, together with comment 1, should do the trick.  Comment 6 leads to rpmbuild error though:

error: line 484: Dependency tokens must begin with alpha-numeric, '_' or '/': Requires(pre): fileutils, module-init-tools, initscripts >= 8.11.1-1, mkinitrd >= 6.0.39-1 %{kernel_fw_prereq}

I think it's because Requires(pre) is inside of "%define kernel_reqprovconf", so maybe it doesn't like the space between %{kernel_prereq} and %{kernel_fw_prereq}\

(In reply to comment #5)
> %define kernel_prereq  ... kernel-firmware >= %{rpmversion}-%{pkg_release}
> 
> With that line in the spec, wouldn't all arches depend on kernel-firmware?  

Yes. That is the intention.

> I think we need a special case here.

Why? Why not just install kernel-firmware?

I see no need for making S390 a special case.

In response to comment 2:

If rpmbuild doesn't produce kernel-firmware on any arch, what is the process to produce this package?  I'm bootstrapping Fedora on a new arch using koji, so it would be nice if rpmbuild produced all necessary packages automatically.

Stepping back though, do we expect that kernel-firmware is necessary on every arch?  Looking through the file list, this looks like firmware for x86* only.  Why the hard dependency on a package most other arches will never need?

The kernel is a special case -- it's built for 'noarch' in addition to the binary architectures. It is the noarch build which produces the kernel-doc and kernel-firmware packages.

The contents of the kernel-firmware package are not only for x86*.

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I did rpmbuild --target noarch, and on s390x there was no kernel-firmware package built.

If the contents of kernel-firmware aren't for x86 only, then can we maintain a list of arches where firmware doesn't apply?  (starting with s390x)

(In reply to comment #13)
> I did rpmbuild --target noarch, and on s390x there was no kernel-firmware
> package built.

What did get built?

Sorry, lost my test system.  I believe this has been worked out in F11, or it's not an issue any more.  Closing.