Bug 1960616

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.

(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?

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).

(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.

(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.

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