Hi,
On 13-02-17 10:05, Nicolas Chauvet wrote:
2017-02-13 9:29 GMT+01:00 Hans de Goede <hdegoede@xxxxxxxxxx>:
Hi all,
redhat-rpm-config in Fedora still contains an ancient copy of kmodtool
back from the days when Fedora allowed kmods directly into the main
Fedora repo, rather then only allowing them in 3th party repositories.
Currently 3th party repositories like rpmfusion (I've put Nicolas
and Leigh from rpmfusion in the Cc) and negativo17 (Simone in the Cc)
maintain and use their own fork.
There are 2 forks actually one maintained by rpmfusion which seems
the most complete / recent but does not support building kabi
packages for EL and various EL repos embed a different copy in
the src.rpm for their kmod packages so that they can build kabi
packages.
As part of the work I've been doing to make it easier to install the
nvidia binary drivers for users who want that, I want to clean up
the situation around kmodtool and aim for one kmodtool version
which does everything needed.
I've been discussing how to do this with Nicolas and Simone and
the plan is:
1) Create a pagure.io repo for kmodtool put the rpmfusion version
there
2) Package the kmodtool from pagure.io in its own kmodtool
package in a way which does not conflict with the ancient copy
from redhat-rpm-config.
3) Once the new packaged version is available, drop the old
kmodtool from newer redhat-rpm-config versions.
4) Extend the new kmodtool to also support creating kabi compliant
packages.
I started with sending this mail to Dan Horák to ask if he was
ok with dropping kmodtool from redhat-rpm-config, but he indicated
that redhat-rpm-config is maintained by the rpm/dnf team, so
hence I'm sending this mail to rpm-software-management now,
with fedora-devel in the Cc to make sure I'm not leaving anyone
out of the loop.
So a few questions for the rpm/dnf team:
1) What do you think of the above plan ?
2) Do you see any issues with dropping kmodtool from redhat-rpm-config
for Fedora ?
3) Would you be willing to drop the old kmodtool for F26+ ?
@Hans
I've took a quick look at kmodtool from redhat-rpm-config and I think
It's only available on EL, not Fedora.
There is a kmodtool sh script installed as /usr/lib/rpm/redhat/kmodtool
by kernel-rpm-macros
Also the kmodtool support is implemented as a script in /usr/bin,
whereas for EL it's implemented as rpm macros.
So as such there is no conflict.
Right, but it would still be good to dump the old stuff, including
/usr/lib/rpm/redhat/kmodtool, as well as the macros calling it,
right ?
Keeping that would just confuse people trying to do kmod packaging
who may stumble over the old, deprecated stuff which we don't want
them to use.
The current "upstream" version is located in the rpmfusion distgit repo itself.
Anyone can fork from our github mirror and start hacking:
https://github.com/rpmfusion/kmodtool
So right now the location of the upstream git doesn't really matter,
In the long run I don't see any issue to move it to pague at some
point.
But my hope as that it can be picked by rpm itslef instead. Specially
as nvidia has started to use it in the CUDA repository for Fedora
(where they use akmod-nvidia based on our design).
So we aren't the only users of that kmodtool support.
I'm fine with keeping https://github.com/rpmfusion/kmodtool as the
upstream for now. Not sure if making kmodtool part of rpm is a good
idea, I've a feeling the group of kmodtool contributors vs the
group of regular rpm contributors don't have much of an overlap,
so a separate repo will be easier (I think).
I think the point of using kabi is just a matter to have a post/postun
snipet in a given kmod-foo that test the availalbility of
/usr/sbin/weak-module and add the weak module support.
This can be easily added after the depmod call either or not the
distro support kABI.(Fedora does not have the weak-module script
anyway).
The symbol extraction feature doesn't seem to be implemented in recent
kmod (tested on oracleasm from centos at least).
As for the design. I think the "template engine" should be better
implemented in RPM macros instead of running a script.
Also I'd like to have some common features used by the kernel
implemented in the default rpm (or redhat-rpm-config), such as signing
and compressing modules:
https://src.fedoraproject.org/cgit/rpms/kernel.git/tree/kernel.spec?h=f23#n1768
https://src.fedoraproject.org/cgit/rpms/kernel.git/tree/kernel.spec?h=f23#n1726
That way, we could re-use the same code for kmod packages.
That sounds like something we can look at eventually.
Is this work worth a f26 feature?
It is not really a user-visible feature, it really just is cleaning
up some technical plumbing stuff. But if people think it is a good
idea to have a feature page to track / coordinate this then I can
create one.
Regards,
Hans
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
