From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C99CCC433DB for ; Mon, 8 Feb 2021 14:33:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 830E064E7C for ; Mon, 8 Feb 2021 14:33:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231697AbhBHOcg (ORCPT ); Mon, 8 Feb 2021 09:32:36 -0500 Received: from mail.kernel.org ([198.145.29.99]:45462 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230365AbhBHObo (ORCPT ); Mon, 8 Feb 2021 09:31:44 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 0698364E30; Mon, 8 Feb 2021 14:31:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1612794663; bh=PVTkT9XfNetRVQQLej8urtw5WMtfDZtgBKilVaw/NsI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=F+5ZFODV4Y39WLJLNM3BPzotmNEs+fxoqfPqm+Sr7MJ1IzzNwE7Iu8b1oMDx0/SZg WiO680PsXSJVJpY05KJqz5u//SAZDDRw4PHW1Qjfz7ZDUOIBHy20Mb/OseLijBg5op yUyZ0yg/1eVsg1WTmFwadJSEXcKrrr/oJqT1Tt5tF9A4EZjW0qufyRkq40KsM0svK1 NkdcbEfaZis79/frpe1Xv2Fk001UInzOCl3QzzpFJmHl4lOELJK+8u1MJlK5QqG41c z/D/4R6anyeyvt5SWVXRezR27og9/pQUUXQAFGjXo9BfPr6Lez32ToOWtcXdx2Y+2O Bn/VxGFCfo8Rg== Date: Mon, 8 Feb 2021 16:31:00 +0200 From: Leon Romanovsky To: Jason Gunthorpe Cc: Honggang Li , Itay Aveksis , RDMA mailing list , Alaa Hleihel , Doug Ledford Subject: Re: rdma-core spec weird behavior on Fedora Message-ID: <20210208143100.GF20265@unreal> References: <20210207080649.GB4656@unreal> <20210208125900.GX4247@nvidia.com> <20210208131053.GC20265@unreal> <20210208132115.GY4247@nvidia.com> <20210208133137.GE20265@unreal> <20210208140824.GC4247@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210208140824.GC4247@nvidia.com> Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org On Mon, Feb 08, 2021 at 10:08:24AM -0400, Jason Gunthorpe wrote: > On Mon, Feb 08, 2021 at 03:31:37PM +0200, Leon Romanovsky wrote: > > On Mon, Feb 08, 2021 at 09:21:15AM -0400, Jason Gunthorpe wrote: > > > On Mon, Feb 08, 2021 at 03:10:53PM +0200, Leon Romanovsky wrote: > > > > On Mon, Feb 08, 2021 at 08:59:00AM -0400, Jason Gunthorpe wrote: > > > > > On Sun, Feb 07, 2021 at 10:06:49AM +0200, Leon Romanovsky wrote: > > > > > > Hi Honggang, > > > > > > > > > > > > Your commit b02de521022a ("redhat: Remove base package dependency from all sub-packages") > > > > > > removes protection from rdma-core when user performs "dnf autoremove". > > > > > > > > > > > > Before your patch, systemd was dependent on libibverbs and latter > > > > > > required rdma-core. After your patch, the last link is lost and > > > > > > rdma-core marked as orphaned package. > > > > > > > > > > > > Any attempt to install rdma-core as standalone package will have the > > > > > > following errors, due to the library dependency of udevadm. > > > > > > [leonro@c rdma-core]$ ldd /sbin/udevadm | grep verbs > > > > > > libibverbs.so.1 => not found > > > > > > > > > > well that makes no sense, since when is udevadm connected to > > > > > libibverbs? > > > > > > > > > > $ ldd `which udevadm` > > > > > linux-vdso.so.1 (0x00007ffcc09ef000) > > > > > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f394bec3000) > > > > > libkmod.so.2 => /lib/x86_64-linux-gnu/libkmod.so.2 (0x00007f394bea8000) > > > > > libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007f394be9d000) > > > > > libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007f394be46000) > > > > > libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f394be1b000) > > > > > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f394bdf8000) > > > > > /lib64/ld-linux-x86-64.so.2 (0x00007f394c1b6000) > > > > > liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f394bdcd000) > > > > > libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f394baf7000) > > > > > libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f394ba67000) > > > > > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f394ba61000) > > > > > > > > This is from my laptop and it is connected: > > > > > > Well, that is crazy, udevadm uses libpcap on Fedora which is linked to verbs > > > > > > But it still doesn't make sense, how did you get a in a situation > > > where this is no libibverbs installed even though there should be > > > dependencies from udevadm preventing that? > > > > It was part of my experiments and it is not the issue which we need to solve. > > > > Our two problems are that "dnf autoremove" removes rdma-core and you can't > > install it separately after Honggang's patch. > > why not? libibverbs should not be removed by autoremoved? During installation of rdma-core, DNF throws errors if libibverbs doesn't exist, which was in my case when I wanted to reinstall rdma-core to something new. Thanks > > Jason