Why are akmod packages arch specific?

[Nicolas Chauvet]

2010/4/26 Nicolas Chauvet <kwizart at gmail.com>:
> 2010/4/24 Thorsten Leemhuis <fedora at leemhuis.info>:
>> On 24.04.2010 03:22, Orcan Ogetbil wrote:
>>> Is there any particular reason?
>>
>> Partly that history iirc, as noarch subpackages were not yet possible in
>> the early akmod days.
>>
>>> Can we make them noarch?
>>
>> Yeah, should be possible, but might be best if tested in rawhide for at
>> least a short while first.
>>
>> But here is another thought I wanted to bring up for discussion months
>> ago: I think it might be easier to build the akmod packages from a
>> separate source package. That way we avoid the flipping the "%define
>> buildforkernels newest" macro when updating the package, which quickly
>> is forgotten, confuses people (afaics), and makes things harder for the
>> one that is pushing the packages and cleaning up old kmod packages in
>> the repos.
>>
>> The downsides: When updating the kmod (e.g. to a newer version or when
>> integrating a new patch) the maintainer would have to copy the
>> foo-kmod.spec file and all the sources to a different directory and flip
>> a bit (the name or a macro). That's a bit more work for the packager,
>> but more "natural" and hence might be easier for everyone.
>>
>> Opinions?
> I cannot understand why to maintain 3 cvs modules for a given kernel
> module (akmod/kmod/kmod-common) would be easier than having to
> maintain only two (kmod/kmod-common) and just switch an option in the
> spec file. At least, it would be easier to split an akmod from the
> kmod-common part instead.
On a second thought, that will not pass when patching only the kernel module.
Hence that will be a severe "duplicate work" if patches need to be
applied once to the akmod, and a second time to the kmod.


> Now, there are a lot of things to solve in the kmod (non-)standard
> before trying to solve non-issue. Here are a few I could suggest:
>
> - akmod modules must be built as soon as a new kernel (or
> kernel-devel) is  installed, not on reboot (as that's not reliable on
> disk controller and kms gpu drivers). This can probably be done with
> %trigger
> - kmod created by akmod must not be replaced by pre-built ones.
> - kABI support on appropriate branches (not much experienced if ever supported).
> - akmod must be noarch package on branches that support that. (if
> built from sub-package).
> - Need to check if an updated kernel module is rebuild if akmod-foo is updated.
> - Once reviewed, kmodtool should be added into rpm itself as that's
> not a separate project, IMO.
>
> Nicolas (kwizart)
>