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. 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. 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 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. Is this work worth a f26 feature? (that could be backported in earlier release at some point anyway). -- - Nicolas (kwizart) _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
