Description of problem: +--------------+---------------+ |component |first build | +--------------+---------------+ |libibverbs | Fedora-6 | +--------------+---------------+ |libmlx4 | Fedora-7 | +--------------+---------------+ |rdma | Fedora-8 | +--------------+---------------+ Before Fedora-23, libmlx4 does not depends/requires 'rdma' package. Here is the history background why libmlx4 depends on 'rdma'/'rdma-core'. Redhat had wrote some scripts for mlx4 kernel driver module probe. Those scripts had been backport to libmlx4 for Fedora-12 in 2009. ===== pkgs.fedoraproject.org/rpms/libmlx4 ===== From ab272eefd4f69810612ba5502c93888f4da2321a Mon Sep 17 00:00:00 2001 From: Doug Ledford <dledford> Date: Wed, 2 Dec 2009 01:17:08 +0000 Subject: [PATCH] - Merge various bits from Red Hat package into Fedora package --- libmlx4-mlx4.conf | 21 +++++++++++++++++++++ libmlx4-modprobe.conf | 1 + libmlx4-setup-mlx4.awk | 18 ++++++++++++++++++ libmlx4.spec | 32 ++++++++++++++++++++++++++------ 4 files changed, 66 insertions(+), 6 deletions(-) create mode 100644 libmlx4-mlx4.conf create mode 100644 libmlx4-modprobe.conf create mode 100644 libmlx4-setup-mlx4.awk ============================================ ===== pkgs.fedoraproject.org/rpms/libmlx4 ===== From 70c735062f6ab5206e9ddcb399838025028d8537 Mon Sep 17 00:00:00 2001 From: Honggang Li <honli> Date: Fri, 8 Apr 2016 00:15:19 -0400 Subject: [PATCH] Move configuration scripts to rdma package Signed-off-by: Honggang Li <honli> --- 0002-libmlx4-add-s390x-platform-support.patch | 212 ++++++++++++++++ libmlx4-1.0.6-compiler-warnings.patch | 18 ++ libmlx4-checksum.mbox | 237 ++++++++++++++++++ libmlx4-mlx4.conf | 27 -- libmlx4-modprobe-2.conf | 21 -- libmlx4-modprobe.conf | 5 - libmlx4-setup.sh | 91 ------- libmlx4.spec | 54 ++-- ======================================================== In 2016, I moved those configuration scripts into 'rdma' package. From that time, the libmlx4 package depends/requires 'rdma' package. After those packages (rdma, libibverbs, provides) and other packages had been merged into 'rdma-core' in upstream, we packaged 'rdma-core' to replace those independent packages. The new sub-packages depends/requires the base package 'rdma-core'. It is helpful for system has RDMA device. Now, we need to minimize the package dependency for Cloud image. Package libpcap was build with IB support. The Cloud image may need libpcap, it pull some packages which unwanted for Cloud user, because dependency libpcap => libibverbs => rdma-core => (other packages required by rdma-core). As the rdma-core package almost just needed for users really have RDMA hardware, they should explicitly install base package 'rdma-core'. Peter had split the libibverbs into libibverbs and libibverbs-core package. The new libibverbs package only includes providers, the VERBs API library into libibverbs-core package. After discussed with rdma-core upstream maintainer, we think it is better to remove the base package dependency. I will apply this patch to fedora-rawhide branch. ====================================================== rdma-core (master)]$ cat a.patch diff --git a/rdma-core.spec b/rdma-core.spec index 13923d3..903da40 100644 --- a/rdma-core.spec +++ b/rdma-core.spec @@ -1,6 +1,6 @@ Name: rdma-core Version: 32.0 -Release: 1%{?dist} +Release: 2%{?dist} Summary: RDMA core userspace libraries and daemons # Almost everything is licensed under the OFA dual GPLv2, 2 Clause BSD license @@ -88,7 +88,6 @@ scripts, dracut rules, and the rdma-ndd utility. %package devel Summary: RDMA core development libraries and headers -Requires: %{name}%{?_isa} = %{version}-%{release} Requires: libibverbs%{?_isa} = %{version}-%{release} Provides: libibverbs-devel = %{version}-%{release} Obsoletes: libibverbs-devel < %{version}-%{release} @@ -141,8 +140,6 @@ compatibility reasons. %package -n libibverbs Summary: A library and drivers for direct userspace use of RDMA (InfiniBand/iWARP/RoCE) hardware -Requires: %{name}%{?_isa} = %{version}-%{release} -Requires: libibverbs-core%{?_isa} = %{version}-%{release} Provides: libcxgb4 = %{version}-%{release} Obsoletes: libcxgb4 < %{version}-%{release} Provides: libefa = %{version}-%{release} @@ -188,12 +185,6 @@ Device-specific plug-in ibverbs userspace drivers are included: - libsiw: A software implementation of the iWarp protocol - libvmw_pvrdma: VMware paravirtual RDMA device -%package -n libibverbs-core -Summary: The main libibverbs library - -%description -n libibverbs-core -The main libibverbs library. - %package -n libibverbs-utils Summary: Examples for the libibverbs library Requires: libibverbs%{?_isa} = %{version}-%{release} @@ -204,7 +195,6 @@ displays information about RDMA devices. %package -n ibacm Summary: InfiniBand Communication Manager Assistant -Requires: %{name}%{?_isa} = %{version}-%{release} %description -n ibacm The ibacm daemon helps reduce the load of managing path record lookups on @@ -218,7 +208,6 @@ library knows how to talk directly to the ibacm daemon to retrieve data. %package -n iwpmd Summary: iWarp Port Mapper userspace daemon -Requires: %{name}%{?_isa} = %{version}-%{release} %description -n iwpmd iwpmd provides a userspace service for iWarp drivers to claim @@ -226,7 +215,6 @@ tcp ports through the standard socket interface. %package -n libibumad Summary: OpenFabrics Alliance InfiniBand umad (userspace management datagram) library -Requires: %{name}%{?_isa} = %{version}-%{release} %description -n libibumad libibumad provides the userspace management datagram (umad) library @@ -235,7 +223,6 @@ are used by the IB diagnostic and management tools, including OpenSM. %package -n librdmacm Summary: Userspace RDMA Connection Manager -Requires: %{name}%{?_isa} = %{version}-%{release} %description -n librdmacm librdmacm provides a userspace RDMA Communication Management API. @@ -252,7 +239,6 @@ Summary: Tools for using the InfiniBand SRP protocol devices Obsoletes: srptools <= 1.0.3 Provides: srptools = %{version}-%{release} Obsoletes: openib-srptools <= 0.0.6 -Requires: %{name}%{?_isa} = %{version}-%{release} %description -n srp_daemon In conjunction with the kernel ib_srp driver, srp_daemon allows you to @@ -353,8 +339,6 @@ rm -f %{buildroot}/%{_sbindir}/srp_daemon.sh %ldconfig_scriptlets -n libibverbs -%ldconfig_scriptlets -n libibverbs-core - %ldconfig_scriptlets -n libibumad %ldconfig_scriptlets -n librdmacm @@ -388,7 +372,6 @@ fi %systemd_postun_with_restart iwpmd.service %files -%license COPYING.* %dir %{_sysconfdir}/rdma %dir %{_docdir}/%{name} %doc %{_docdir}/%{name}/README.md @@ -427,6 +410,7 @@ fi %{_unitdir}/rdma-ndd.service %{_mandir}/man7/rxe* %{_mandir}/man8/rdma-ndd.* +%license COPYING.* %files devel %doc %{_docdir}/%{name}/MAINTAINERS @@ -565,16 +549,13 @@ fi %dir %{_sysconfdir}/libibverbs.d %dir %{_libdir}/libibverbs %{_libdir}/libefa.so.* +%{_libdir}/libibverbs*.so.* %{_libdir}/libibverbs/*.so %{_libdir}/libmlx5.so.* %{_libdir}/libmlx4.so.* %config(noreplace) %{_sysconfdir}/libibverbs.d/*.driver %doc %{_docdir}/%{name}/libibverbs.md -%files -n libibverbs-core -%license COPYING.* -%{_libdir}/libibverbs*.so.* - %files -n libibverbs-utils %{_bindir}/ibv_* %{_mandir}/man1/ibv_* @@ -663,6 +644,9 @@ fi %endif ====================================================== [1] git://git.kernel.org/pub/scm/libs/infiniband/libmlx4.git [2] https://downloads.openfabrics.org/libmlx4/ Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 1733018 [details] remove base package dependency
Doug, Jarod, Peter Please let me know if you have any concern.
(In reply to Honggang LI from comment #2) > Doug, Jarod, Peter > Please let me know if you have any concern. Lots, what does this actually achieve? It looks to be just reverting my change, which in turn pulls in a bunch of crap for non IB users which is basically the entire world.
(In reply to Peter Robinson from comment #3) > Lots, what does this actually achieve? As sub-packages no longer depends on base package rdma-core, install libpcap will not pull rdma-core and packages it depends on. > It looks to be just reverting my change, Yes, it reverts your change. It also move sub-package dependency of base package rdma-core. > which in turn pulls in a bunch of crap for non IB users which is > basically the entire world. No, it will not pull rdma-core and packages it depends on for non IB users. Users will have to explicitly install rdma-core package.
Please link to a scratch build of the proposed changes, I still think it will pull in extra unnecessary pieces.
https://koji.fedoraproject.org/koji/taskinfo?taskID=56276349
Hi, Peter, please test this new scratch build. The old scratch may be deleted. https://koji.fedoraproject.org/koji/taskinfo?taskID=58950671
So this improves the situation but the only library that libpcap depends on is libibverbs.so.1, which is why I split it out to the libibverbs-core sub package. It's 136K in size. The whole of libibverbs is over 1mb in size including a whole bunch of device specific driver libraries. For things like RHEL for Edge and cloud images this provides extra delta we don't need. The idea of libibverbs-core is that libibverbs depends on libibverbs-core and hence when libibverbs is installed the libibverbs-core is also always installed so for IB installs it will always work as intended, but for all the other use cases that don't care about IB we don't end up with a bunch of things, both within and outside of libibverbs that we don't need, it's just the bare minimum required by libpcap.
(In reply to Peter Robinson from comment #8) > So this improves the situation but the only library that libpcap depends on > is libibverbs.so.1, which is why I split it out to the libibverbs-core sub > package. It's 136K in size. > > The whole of libibverbs is over 1mb in size including a whole bunch of > device specific driver libraries. For things like RHEL for Edge and cloud > images this provides extra delta we don't need. 1mb extra size looks acceptable for me, as system can offer 1mb disk or memory space in nowadays. > The idea of libibverbs-core is that libibverbs depends on libibverbs-core > and hence when libibverbs is installed the libibverbs-core is also always > installed so for IB installs it will always work as intended, but for all > the other use cases that don't care about IB we don't end up with a bunch of > things, both within and outside of libibverbs that we don't need, it's just > the bare minimum required by libpcap. Understood. Cutting of base sub-package dependency is some kind of compromise for libpcap usage and upstream. I will apply this patch for Fedora and backport it for upstream repo in github.
> 1mb extra size looks acceptable for me, as system can offer 1mb disk or > memory > space in nowadays. In a data centre with multi gigabits per second like you'd get with IB, in the RHEL for Edge use case where there's still a lot of use cases with satellite comms and 64kbps committed information rate customers would vehementlyd disagree.
What is the size of a typical RHEL Edge image? What is the size of image created by you with my scratch rdma-core build? Thanks
(In reply to Honggang LI from comment #11) > What is the size of a typical RHEL Edge image? What is the size of image > created by you with my scratch rdma-core build? Too big, we're looking all over place for reductions :)
(In reply to Peter Robinson from comment #12) > (In reply to Honggang LI from comment #11) > > What is the size of a typical RHEL Edge image? What is the size of image > > created by you with my scratch rdma-core build? > > Too big, we're looking all over place for reductions :) I understand your effort to reduce the size of Edge image. Given the typical size of an Edge image, extra 1mb size looks good at this point. I will apply my patch and backport for upstream repo in github.
So, this change appears to be breaking things... Dependencies resolved. ========================================================================================================================== Package Architecture Version Repository Size ========================================================================================================================== Upgrading: libibverbs x86_64 33.0-1.fc34 koji 334 k rdma-core x86_64 33.0-1.fc34 koji 56 k Transaction Summary ========================================================================================================================== Upgrade 2 Packages Total download size: 390 k Is this ok [y/N]: y Downloading Packages: (1/2): rdma-core-33.0-1.fc34.x86_64.rpm 109 kB/s | 56 kB 00:00 (2/2): libibverbs-33.0-1.fc34.x86_64.rpm 477 kB/s | 334 kB 00:00 -------------------------------------------------------------------------------------------------------------------------- Total 553 kB/s | 390 kB 00:00 Running transaction check Transaction check succeeded. Running transaction test The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: Transaction test error: file /usr/lib64/libibverbs.so.1 from install of libibverbs-33.0-1.fc34.x86_64 conflicts with file from package libibverbs-core-32.0-1.fc34.x86_64 If you are dropping that subpackage, you need to provide/obsolate it?
> You can remove cached packages by executing 'dnf clean packages'. > Error: Transaction test error: > file /usr/lib64/libibverbs.so.1 from install of > https://drive.google.com/file/d/1QbdxixXNZcwVAY3CDEF2FMxsRsNJTjIy/view-33.0-1.fc34.x86_64 conflicts with file from package > libibverbs-core-32.0-1.fc34.x86_64 So libibverbs-core needs to be obsoleted by libibverbs
Can we file a ticket to delete rdma-core-32.0-1.fc34 build? It is the only build has sub-package (libibverbs-core). rdma-core-32.0-1.fc34 is a rawhide build.
I've untagged that build, it won't go out in the next compose.
(In reply to Kevin Fenzi from comment #17) > I've untagged that build, Which build? rdma-core-32.0-1.fc34?
(In reply to Honggang LI from comment #16) > Can we file a ticket to delete rdma-core-32.0-1.fc34 build? It is the only > build has sub-package (libibverbs-core). > rdma-core-32.0-1.fc34 is a rawhide build. Oh, no. It is my bad. rdma-core-31.0-2.fc34 is the only build has sub-package (libibverbs-core). https://koji.fedoraproject.org/koji/buildinfo?buildID=1610742
(In reply to Honggang LI from comment #16) > Can we file a ticket to delete rdma-core-32.0-1.fc34 build? It is the only > build has sub-package (libibverbs-core). > rdma-core-32.0-1.fc34 is a rawhide build. But that won't solve the problem for users upgrades, we need to have libibverbs-core to be obsoleted by libibverbs
(In reply to Peter Robinson from comment #20) > But that won't solve the problem for users upgrades, Yes, it will impact Fedora-Rawhide (FC34) users who want to upgrade rdma-core. I think it is a temporary issue. Once we have Fedora-34 GA out with rdma-core-33 , FC34 users will not have trouble with this. > we need to have libibverbs-core to be obsoleted by libibverbs If add this obsoleted tag for this temporary issue, we will have to keep it. Is this really worth?
> If add this obsoleted tag for this temporary issue, we will have to keep it. > > Is this really worth? It's a one line addition to the spec file, what's the problem?
(In reply to Peter Robinson from comment #22) > It's a one line addition to the spec file, what's the problem? This will introduce divergence between RHEL9 and Fedora. RHEL9 is internal at this moment. RHEL9 users will not aware exist of libibverbs-core sub-package. Because the internal build will be replaced with rdma-core-33 or higher. The same thing also apply for upstream github repo and Fedora. The divergence like this is source regression issue. So, we try our best to avoid divergence.
it could go in all versions of the spec without issue and hence not create any divergence.
OK, let's add the obsoleted tag for Fedora-34, and remove it for Fedora-35. That will make everyone happy.
Added obsoleted tag for rdma-core-33.0-2.fc34 .