(In reply to jcastran from comment #0)
> Description of problem:
> Users can not install both .i686 and .x86_64 architectures of gdb-headless
> 
> Version-Release number of selected component (if applicable):
> gdb-headless-8.2-6.el8.i686
> gdb-headless-8.2-6.el8_0.x86_64 or gdb-headless-8.2-6.el8.x86_64
> 
> 
> How reproducible:
> Everytime
> 
> Steps to Reproduce:
> 1. yum install gdb-headless.i686
> 2.
> 3.
> 
> Actual results:
>   file /usr/share/gdb/guile/gdb.go conflicts between attempted installs of
> gdb-headless-8.2-6.el8.i686 and gdb-headless-8.2-6.el8_0.x86_64
>   file /usr/share/gdb/guile/gdb/experimental.go conflicts between attempted
> installs of gdb-headless-8.2-6.el8.i686 and gdb-headless-8.2-6.el8_0.x86_64
>   file /usr/share/gdb/guile/gdb/iterator.go conflicts between attempted
> installs of gdb-headless-8.2-6.el8.i686 and gdb-headless-8.2-6.el8_0.x86_64
>   file /usr/share/gdb/guile/gdb/printing.go conflicts between attempted
> installs of gdb-headless-8.2-6.el8.i686 and gdb-headless-8.2-6.el8_0.x86_64
>   file /usr/share/gdb/guile/gdb/support.go conflicts between attempted
> installs of gdb-headless-8.2-6.el8.i686 and gdb-headless-8.2-6.el8_0.x86_64
>   file /usr/share/gdb/guile/gdb/types.go conflicts between attempted
> installs of gdb-headless-8.2-6.el8.i686 and gdb-headless-8.2-6.el8_0.x86_64
>   file /usr/share/man/man1/gdb-add-index.1.gz conflicts between attempted
> installs of gdb-headless-8.2-6.el8.i686 and gdb-headless-8.2-6.el8_0.x86_64
>   file /usr/share/man/man1/gdb.1.gz conflicts between attempted installs of
> gdb-headless-8.2-6.el8.i686 and gdb-headless-8.2-6.el8_0.x86_64
>   file /usr/share/man/man5/gdbinit.5.gz conflicts between attempted installs
> of gdb-headless-8.2-6.el8.i686 and gdb-headless-8.2-6.el8_0.x86_64

Hi, thanks for the report.

I'm wondering why a user would want to install both x86_64 and i686 versions of gdb-headless, though.  Given that a x86_64 GDB should be able to debug an i686 application, I don't see a reason initially to install both packages at the same system.

Thanks in advance.

We're investigating a (semi-ugly) workaround for this issue.

I was able to "solve" this in a semi-ugly way, as David said.

The idea is to do two things:

1) Use "ExcludeArch: %{ix86}" in order to completely disable i686 RPMs from being built.  This should take care of fresh installs of future RHEL 8 releases.

2) Due to the fact that we already shipped i686 RPMs for RHEL 8.1, and that the user might have inadvertently installed them, we had to figure out a way to avoid this gdb-headless conflict.  There is no easy way to do that, so I chose to use "Obsoletes: gdb(x86-32)" *and* "Provides: gdb(x86-32)" in the specfile (provided that arch == x86_64).  Unfortunately the "Obsoletes" thing works only when doing "dnf update", and that's the reason I also had to use "Provides", which makes it really ugly (after all, the x86_64 GDB RPM is not actually providing the i686 GDB binary).  Given that RHEL 8 does not officially support i686, though, this solution should be fine.

I tested it by generating x86_64 RPM packages with these options in place, locally installing them (on a RHEL 8 machine), and then trying to "dnf install librevenge-gdb.i686", which is the package that depends on gdb-headless.i686.  With this new x86_64 GDB installed, dnf did not try to install gdb.i686 nor gdb-headless.i686 anymore.

Hi,

(In reply to Sergio Durigan Junior from comment #5)
> I was able to "solve" this in a semi-ugly way, as David said.
> 
> The idea is to do two things:
> 
> 1) Use "ExcludeArch: %{ix86}" in order to completely disable i686 RPMs from
> being built.  This should take care of fresh installs of future RHEL 8
> releases.

As a side-effect, this also took care of rhel-8.2 buildroot in brew.

While we may not support RHEL8 on i686, we do build for in brew. Due to missing dependencies, rpm-build package can't be installed which in turn makes any builds fail on i686.

In fact, it fails *all* builds in RHEL 8.2 because a failure on one of the targets is enough to fail a complete build.

As result, this is RHEL 8.2 blocker.

The offending build has been untagged from RHEL 8.2.0.

*** Bug 1792363 has been marked as a duplicate of this bug. ***

The situation has been solved by untagging the build, so I'm clearing the NEEDINFO request.

After a very long discussion involving RCM, releng, our team, and my conscience, I decided that this bug is not GDB's fault, but librevenge's, and therefore I am reassigning the bug to them.

If we disconsider the fact that the GDB i686 RPM was shipped without our knowledge/approval, the underlying cause for this bug is the fact that librevenge.spec contains:

  Requires: gdb%{?_isa}

The %{?_isa} part is wrong/unnecessary, since GDB x86_64 can debug i686 applications just fine.  At least, this line should be changed to:

  Requires: gdb

But even that may seem "too much".  I understand that we're talking about a subpackage that contains GDB-specific files to enable pretty-printing on librevenge, but I think it shouldn't depend on GDB, but recommend it instead:

  Recommends: gdb

Another good point (raised by Jan Kratochvil) is that perhaps the "librevenge-gdb" subpackage should be retired.  Since its goal is to provide scripts to make the GDB experience better, then maybe these scripts should be included in the librevenge-devel or even the librevenge-debuginfo package.  But this last part can be seen as optional; the real fix is the removal of the %{?_isa} part, as mentioned above.

I'm attaching a patch to implement both ideas (i.e., remove the %{?_isa} and s/Requires/Recommends/).  Let me know if you want me to push it to the repository, or if you prefer to take it from here.

Thanks.

Created attachment 1653166 [details]
librevenge.spec patch

git blame suggest that the line has been

Requires: gdb%{?_isa}

since 2015, seems very odd that it becomes a problem now,

(In reply to Caolan McNamara from comment #15)
> git blame suggest that the line has been
> 
> Requires: gdb%{?_isa}
> 
> since 2015, seems very odd that it becomes a problem now,

Yeah, this whole bug is odd, TBH.

Something that I still don't fully understand is why librevenge.i686 is being shipped on RHEL 8.  Since it's a library, some other i686 program must depend on it.  And then there's the question of why librevenge.i686 (and librevenge-gdb.i686) is being pulled by kickstart during installation.

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, 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-2020:1743