Thorsten Leemhuis wrote:
Please don't use the term "-kmod-common" in the package name; just
call it "broadcom-hybrid-wl" and add
Provides: broadcom-hybrid-wl-kmod-common = %{version}-%{release}
Thinking about it some more: Maybe the best scheme for both packages
might be:
"kmod-wl" for the kmod package
"broadcom-hybrid-wl" for the second "userland" package (which then
needs to provide wl-kmod-common = %{version}-%{release})
Opinions?
As an end user I find that slightly confusing to have so many different
permutations. I would find it less confusing to do your original way and
drop the "hybrid" altogether:
"kmod-wl" for the kmod package
"broadcom-wl" for the "userland" package which provides
broadcom-wl-common = %{version}-%{release}
Thoughts?
broadcom-hybrid-wl-kmod-debuginfo-5.10.27.6-2.fc9.x86_64.rpm
I don't fully understand the first two - the second one contains the
actual kernel module but
a) why is the name of the second package formed like it is - I am
supposing that it is because it is built for a specific kernel version?
Correct. The first is the base package. People say 'yum install
kmod-broadcom-hybrid_wl', and get that package, and the latest
kernel-specific one, which is what the second package is. The
2.6.26.6-79.fc9.x86_64 in the name is actually the uname -r for the
kernel it was built for.
b) what is the first package for? it is empty!
Virtual package, so people don't have to request the driver including
the kernel version. (The kernel version in there is actually part of the
rpm name, not part of the rpm version).
More important: that empty package always tracks in the latest kmod
package (the one with the modules in it) automatically on update; that
would not happen otherwise due to the "uname -r" in the name of the
package which holds the modules.
CU
knurd
Thanks for this info guys, makes perfect sense now. I kinda mostly
figured this out but got too tired last night to respond.
Cheers
Chris
