Summary: RFE: dnf should be able to automatically select driver packages for installation --- Description: Description of problem: We are looking for a way to use either yum or dnf to install required RPM packages from a repository of drivers we provide to our customers, depending on the hardware present in the customer's server. As an example, here is our repository for RHEL 9.0: https://patches.ts.fujitsu.com/linux/pldp/RHEL9/rhel9/ The RPM packages already contain "provides" properties which look like: # rpm -q --provides -p kmod-mlnx-en-5.7-3.el9.0.x86_64.rpm | grep modalias modalias(auxiliary:mlx5_core.eth) = 5.7_1.0.2 modalias(auxiliary:mlx5_core.eth-rep) = 5.7_1.0.2 modalias(auxiliary:mlx5_core.sf) = 5.7_1.0.2 modalias(pci:v000015B3d0000101[3456789ABCDEF]sv*sd*bc*sc*i*) = 5.7_1.0.2 modalias(pci:v000015B3d0000102[13]sv*sd*bc*sc*i*) = 5.7_1.0.2 modalias(pci:v000015B3d0000A2D[236CF]sv*sd*bc*sc*i*) = 5.7_1.0.2 It appears that the v... and d... (e.g. "cv000015B3d0000A2D") correspond to PCIe vendor and device codes of the respective hardware. Version-Release number of selected component (if applicable): N/A How reproducible: always Steps to Reproduce: 1. Try to install only those RPM packages from a repository of drivers which correspond to the hardware of a system Actual results: You have to manually specify the correct packages which are needed for a specific hardware configuration Expected results: There is an option available in yum/dnf which automatically installs only the required hardware driver packages from a repository which contains many more driver packages Additional info: This works fine with e.g. SUSE's SLES 15. They provide a special option to their dnf equivalent called "zypper". Their documentation can be found here: https://documentation.suse.com/sles/15-SP4/html/SLES-all/cha-sw-cl.html#sec-zypper-softman-util Provided the corresponding YUM repository is registered (below referred to as "PRIMERGY PLDP") one may use the following command: zypper install-new-recommends --no-recommends -r "PRIMERGY PLDP" This will then check the existing hardware (USB & PCIe IDs, etc.) and select all RPM packages with matching "modalias" patterns. We are looking for a similar functionality of RHEL, e.g. using yum or dnf which will then trigger the selection and installation of RPM package matching the system's installed hardware configuration. This should not require to provide the driver name and/or the PCIe codes on the command line.
Can you give me more details about the repository that you are installing from and what the expected user workflow would be for this? Are you expecting the main dnf transaction to automatically add driver packages for hardware present in the system or are you expecting that to be a distinct operation from regular dnf operations?
(In reply to David Cantrell from comment #1) > Can you give me more details about the repository that you are installing > from and what the expected user workflow would be for this? Are you > expecting the main dnf transaction to automatically add driver packages for > hardware present in the system or are you expecting that to be a distinct > operation from regular dnf operations? Sorry for the delayed answer, just didn't get a notification that there was an answer pending. The repository we are installing from is https://patches.ts.fujitsu.com/linux/pldp/RHEL9/rhel9/ Regarding the expected user workflow: A user might use dnf install-by-modalias [-r “<name of repository>”] which would then check with the system’s PCIe/USB etc. components whether or not a RPM package’s “modalias” provides entries in each or the provided repository matches. Those packages are then (proposed to be) installed.
OK, thanks for the clarification. I am going to take a look at this in more detail and see what plan I can come up with. My initial thought is this is going to be out of scope for core dnf functionality, but it is ideal for a dnf plugin. But let me play around with this for some days and post here with an update next week.
Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.