Is there any particular reason?

Can we make them noarch?

On 2010/04/24 8:16 AM, Thorsten Leemhuis wrote: > > 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? +1. I think this is more intuitive and copying the spec if not a big deal anyways - just 'cvs diff -u' then 'patch < /path/to/diff' wherever needed.

2010/4/24 Thorsten Leemhuis <fedora(a)leemhuis.info&gt;: > 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.

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)