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