2010/4/26 Nicolas Chauvet <kwizart(a)gmail.com>:
2010/4/24 Thorsten Leemhuis <fedora(a)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)