RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1960616 - libcomps rebase causes dependencies on AppStream packages
Summary: libcomps rebase causes dependencies on AppStream packages
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: libcomps
Version: 8.5
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: beta
: ---
Assignee: Packaging Maintenance Team
QA Contact: Jan Blazek
Mariya Pershina
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-05-14 11:57 UTC by Josh Boyer
Modified: 2021-11-10 08:16 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
.`libdnf-devel` upgrade fails if the CodeReady Linux Builder repository is not available on the system The `libdnf-devel` package has been moved from the BaseOS to CodeReady Linux Builder repository. Consequently, upgrading `libdnf-devel` fails if the CodeReady Linux Builder repository is not available on the system. To work around this problem, enable the CodeReady Linux Builder repository, or remove the `libdnf-devel` package prior to the upgrade.
Clone Of:
Environment:
Last Closed: 2021-11-09 19:41:03 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2021:4407 0 None None None 2021-11-09 19:41:05 UTC

Description Josh Boyer 2021-05-14 11:57:21 UTC 
Description of problem:

libcomps is a BaseOS package and cannot have runtime dependencies outside of BaseOS.  The recent rebase caused libcomps-devel to grow runtime dependencies on libxml2-devel and transitively cmake-filesystem.  Those two packages are now incorrectly being pulled into BaseOS


        Following packages were moved from AppStream to BaseOS:

            - cmake  (src)

            - cmake-filesystem  (aarch64, ppc64le, s390x, x86_64)

            - libxml2-devel  (aarch64, s390x, ppc64le, x86_64)

Please correct.


Version-Release number of selected component (if applicable):

libcomps-0.1.16-1.el8
Comment 1 Daniel Mach 2021-05-14 15:06:34 UTC 
This is probably the change that caused it:
 %files devel
+%{_libdir}/pkgconfig/%{name}.pc

I suppose it triggers auto-generation of
Requires: pkgconfig(libxml-2.0)


Josh,
what do you suggest us to do?

We could remove the .pc file or the dependency,
but that would keep libcomps-devel broken.
Libxml2-devel has always been needed in the public headers
and this dependency change fixes the problem.

We could also move the devel package(s) to CRB,
but I'm not sure if it's the right thing to do.
Comment 2 Josh Boyer 2021-05-18 13:28:14 UTC 
(In reply to Daniel Mach from comment #1)
> This is probably the change that caused it:
>  %files devel
> +%{_libdir}/pkgconfig/%{name}.pc
> 
> I suppose it triggers auto-generation of
> Requires: pkgconfig(libxml-2.0)
> 
> 
> Josh,
> what do you suggest us to do?
> 
> We could remove the .pc file or the dependency,
> but that would keep libcomps-devel broken.
> Libxml2-devel has always been needed in the public headers
> and this dependency change fixes the problem.
> 
> We could also move the devel package(s) to CRB,
> but I'm not sure if it's the right thing to do.

Adding Kyle.

So moving libcomps-devel to CRB would be the more complete solution.  The library is already ACG 2 (so I hope this rebase didn't change the ABI.  If it does, we have other problems...) and moving the -devel package to CRB isn't going to change that.  However, it leaves an issue in that customers that have it installed from the BaseOS repo are going to run into update problems if they don't have CRB enabled.  I suspect the number of customers have have this installed is rather small, so maybe this could be a release note.

Kyle, thoughts?
Comment 3 Kyle Walker 2021-06-01 19:03:28 UTC 
My immediate reaction is to keep libcomps-devel in AppStream if at all possible...

I believe the suspicion is correct, we likely have a small number of customers that would see the update path problem. However, the error that would be emitted is not intuitive at all:

# yum update --disablerepo=\* --enablerepo AppStream --enablerepo BaseOS -x libcomps-devel-0.1.16-1.el8.x86_64
Updating Subscription Management repositories.
Last metadata expiration check: 0:01:22 ago on Tue 01 Jun 2021 02:50:49 PM EDT.
Error: 
 Problem 1: cannot install both libcomps-0.1.16-1.el8.x86_64 and libcomps-0.1.11-5.el8.x86_64
  - package libcomps-devel-0.1.11-5.el8.x86_64 requires libcomps.so.0.1.11()(64bit), but none of the providers can be installed
  - package libcomps-devel-0.1.11-5.el8.x86_64 requires libcomps(x86-64) = 0.1.11-5.el8, but none of the providers can be installed
  - cannot install the best update candidate for package libcomps-0.1.11-5.el8.x86_64
  - problem with installed package libcomps-devel-0.1.11-5.el8.x86_64
 Problem 2: cannot install both libcomps-0.1.16-1.el8.x86_64 and libcomps-0.1.11-5.el8.x86_64
  - package python3-libcomps-0.1.16-1.el8.x86_64 requires libcomps.so.0()(64bit), but none of the providers can be installed
  - package python3-libcomps-0.1.16-1.el8.x86_64 requires libcomps(x86-64) = 0.1.16-1.el8, but none of the providers can be installed
  - package libcomps-devel-0.1.11-5.el8.x86_64 requires libcomps.so.0.1.11()(64bit), but none of the providers can be installed
  - package libcomps-devel-0.1.11-5.el8.x86_64 requires libcomps(x86-64) = 0.1.11-5.el8, but none of the providers can be installed
  - cannot install the best update candidate for package python3-libcomps-0.1.11-5.el8.x86_64
  - cannot install the best update candidate for package libcomps-devel-0.1.11-5.el8.x86_64
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)


The error is correct, but it leaves doesn't lend itself to the "you need to enable a repo you didn't have before, because, of something that we did" or "you should consider removing libcomps-devel before this update" action. The Release Notes would only cover the instance of an end user thoroughly reviewing them, and knowledgebase articles aren't much more help there either (due to the various versions that could be emitted in the error splat).
Comment 4 Josh Boyer 2021-06-03 11:57:42 UTC 
(In reply to Kyle Walker from comment #3)
> My immediate reaction is to keep libcomps-devel in AppStream if at all
> possible...

Did you mean BaseOS here?

 
> I believe the suspicion is correct, we likely have a small number of
> customers that would see the update path problem. However, the error that
> would be emitted is not intuitive at all:
> 
> # yum update --disablerepo=\* --enablerepo AppStream --enablerepo BaseOS -x
> libcomps-devel-0.1.16-1.el8.x86_64
> Updating Subscription Management repositories.
> Last metadata expiration check: 0:01:22 ago on Tue 01 Jun 2021 02:50:49 PM
> EDT.
> Error: 
>  Problem 1: cannot install both libcomps-0.1.16-1.el8.x86_64 and
> libcomps-0.1.11-5.el8.x86_64
>   - package libcomps-devel-0.1.11-5.el8.x86_64 requires
> libcomps.so.0.1.11()(64bit), but none of the providers can be installed
>   - package libcomps-devel-0.1.11-5.el8.x86_64 requires libcomps(x86-64) =
> 0.1.11-5.el8, but none of the providers can be installed
>   - cannot install the best update candidate for package
> libcomps-0.1.11-5.el8.x86_64
>   - problem with installed package libcomps-devel-0.1.11-5.el8.x86_64
>  Problem 2: cannot install both libcomps-0.1.16-1.el8.x86_64 and
> libcomps-0.1.11-5.el8.x86_64
>   - package python3-libcomps-0.1.16-1.el8.x86_64 requires
> libcomps.so.0()(64bit), but none of the providers can be installed
>   - package python3-libcomps-0.1.16-1.el8.x86_64 requires libcomps(x86-64) =
> 0.1.16-1.el8, but none of the providers can be installed
>   - package libcomps-devel-0.1.11-5.el8.x86_64 requires
> libcomps.so.0.1.11()(64bit), but none of the providers can be installed
>   - package libcomps-devel-0.1.11-5.el8.x86_64 requires libcomps(x86-64) =
> 0.1.11-5.el8, but none of the providers can be installed
>   - cannot install the best update candidate for package
> python3-libcomps-0.1.11-5.el8.x86_64
>   - cannot install the best update candidate for package
> libcomps-devel-0.1.11-5.el8.x86_64
> (try to add '--allowerasing' to command line to replace conflicting packages
> or '--skip-broken' to skip uninstallable packages or '--nobest' to use not
> only best candidate packages)
> 
> 
> The error is correct, but it leaves doesn't lend itself to the "you need to
> enable a repo you didn't have before, because, of something that we did" or
> "you should consider removing libcomps-devel before this update" action. The
> Release Notes would only cover the instance of an end user thoroughly
> reviewing them, and knowledgebase articles aren't much more help there
> either (due to the various versions that could be emitted in the error
> splat).

That forces parts of cmake and libxml2-devel to be in BaseOS.  One way or another, packages are moving across repos to resolve this.  It is not the end of the world, but I'm wondering if we have data on the number of systems that have libcomps-devel installed.  If this is a tens of users kind of problem, I'd rather correct it to what we consider to be the proper solution.
Comment 5 Kyle Walker 2021-06-03 18:33:39 UTC 
(In reply to Josh Boyer from comment #4)
> Did you mean BaseOS here?

Ugh, yes... Sorry about that. I realize now, 24 hours later, that I was transposing libxml2-devel and libcomps-devel...


> That forces parts of cmake and libxml2-devel to be in BaseOS.  One way or
> another, packages are moving across repos to resolve this.  It is not the
> end of the world, but I'm wondering if we have data on the number of systems
> that have libcomps-devel installed.  If this is a tens of users kind of
> problem, I'd rather correct it to what we consider to be the proper solution.

I have been digging in the data I currently have, and it is looking like a "tens of users" type of situation. With that being the case, then I would say the best option is moving libcomps-devel to CRB. I would request a Release Notes update for the change (via PES) and I can see about closing the reactive loop via a new knowledgebase article if/when the change goes live.
Comment 16 errata-xmlrpc 2021-11-09 19:41:03 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (libcomps bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:4407
Note You need to log in before you can comment on or make changes to this bug.