| Summary: | file /usr/share/man/man1/gcore.1.gz from install of gdb-7.12-29.fc25.x86_64 conflicts with file from package gdb-headless-7.12-24.fc25.x86_64 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Sidney Sedlak <dev> |
| Component: | gdb | Assignee: | Rex Dieter <rdieter> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 25 | CC: | gbenson, jan.kratochvil, packaging-team-maint, palves, pmuldoon, rdieter, redhat-bugzilla, rpm-software-management, sergiodj, tom, vmukhame |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-01-04 09:59:38 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Sidney Sedlak
2016-12-07 19:45:47 UTC
After installing Fedora-Workstation-Live-x86_64-25-1.3.iso I had: gdb-7.12-24.fc25.x86_64 gdb-headless-7.12-24.fc25.x86_64 After 'dnf update' I had: gdb-7.12-29.fc25.x86_64 gdb-headless-7.12-29.fc25.x86_64 I have the problem unreproducible. Also I do not see any packaging mistake myself. Please reopen it with more specific reproducibility instructions. I have run into the exact same error.
{{{
Transaction check error: file /usr/share/man/man1/gcore.1.gz from install of gdb-7.12-29.fc25.x86_64 conflicts with file from package gdb-headless-7.12-24.fc25.x86_64
}}}
Details
{{{
$ rpm -qa | egrep "gdb-7.12|gdb-headless"
gdb-7.12-24.fc25.x86_64
gdb-headless-7.12-24.fc25.x86_64
gdb-headless-7.12-29.fc25.x86_64
$ cat /etc/fedora-release
Fedora release 25 (Twenty Five)
$ uname -a
Linux (snip)-lnx-f25 4.8.6-300.fc25.x86_64 #1 SMP Tue Nov 1 12:36:38 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
}}}
This was immediately reproducible after a base installation of Fedora-Workstation-Live-x86_64-25-1.3.iso.
How to re-open the bug? (I see no mechanism in the status workflow...) Oh, btw, repos enabled are:
{{{
$ sudo dnf repolist
Last metadata expiration check: 1:29:57 ago on Sun Jan 1 13:44:00 2017.
repo id repo name status
*fedora Fedora 25 - x86_64 51,669
spacewalk-client Spacewalk Client Tools 27
*updates Fedora 25 - x86_64 - Updates 13,349
$ pwd
/etc/yum.repos.d
$ ll
total 24
-rw-r--r--. 1 root root 689 Nov 3 11:13 fedora-cisco-openh264.repo
-rw-r--r--. 1 root root 1251 Nov 3 11:13 fedora.repo
-rw-r--r--. 1 root root 1270 Nov 3 11:13 fedora-updates.repo
-rw-r--r--. 1 root root 1328 Nov 3 11:13 fedora-updates-testing.repo
}}}
(In reply to Fermulator from comment #2) > gdb-headless-7.12-24.fc25.x86_64 > gdb-headless-7.12-29.fc25.x86_64 This must not happen - the rpm database is inconsistent in such case. But that is a problem of dnf, not gdb. I do not know how that can happen. Repair of rpm database should be: dnf remove --duplicates @Igore why "NOTABUG"? The only "duplicate" keyword in the dnf man page is:
{{{
$ dnf --help | grep dup
--showduplicates show duplicates, in repos, in list/search commands
}}}
So the recommended "dnf remove --duplicates" is not available.
Let's try to remove the OLDER package manually...
{{{
$ rpm -qa | grep gdb-headless
gdb-headless-7.12-24.fc25.x86_64
gdb-headless-7.12-29.fc25.x86_64
$ sudo dnf remove gdb-headless-7.12-24.fc25.x86_64
This system is receiving updates from Spacewalk server.
Dependencies resolved.
========================================================================================================================================================================================
Package Arch Version Repository Size
========================================================================================================================================================================================
Removing:
abrt-addon-ccpp x86_64 2.9.0-1.fc25 @anaconda 308 k
abrt-addon-coredump-helper x86_64 2.9.0-1.fc25 @anaconda 34 k
abrt-addon-kerneloops x86_64 2.9.0-1.fc25 @anaconda 72 k
abrt-addon-pstoreoops x86_64 2.9.0-1.fc25 @anaconda 14 k
abrt-addon-python3 x86_64 2.9.0-1.fc25 @anaconda 18 k
abrt-addon-vmcore x86_64 2.9.0-1.fc25 @anaconda 43 k
abrt-addon-xorg x86_64 2.9.0-1.fc25 @anaconda 50 k
abrt-cli x86_64 2.9.0-1.fc25 @anaconda 0
abrt-desktop x86_64 2.9.0-1.fc25 @anaconda 0
abrt-gui x86_64 2.9.0-1.fc25 @anaconda 226 k
abrt-gui-libs x86_64 2.9.0-1.fc25 @anaconda 27 k
abrt-plugin-bodhi x86_64 2.9.0-1.fc25 @anaconda 26 k
abrt-retrace-client x86_64 2.9.0-1.fc25 @anaconda 108 k
abrt-tui x86_64 2.9.0-1.fc25 @anaconda 24 k
elfutils x86_64 0.167-2.fc25 @anaconda 815 k
gcc-gdb-plugin x86_64 6.3.1-1.fc25 @updates 147 k
gdb x86_64 7.12-24.fc25 @anaconda 0
gdb-headless x86_64 7.12-24.fc25 @anaconda 10 M
gnome-abrt x86_64 1.2.4-3.fc25 @anaconda 904 k
libreport-fedora x86_64 2.8.0-1.fc25 @anaconda 41 k
libreport-plugin-kerneloops x86_64 2.8.0-1.fc25 @anaconda 38 k
libreport-plugin-logger x86_64 2.8.0-1.fc25 @anaconda 39 k
python3-humanize noarch 0.5.1-5.fc25 @anaconda 56 k
python3-inotify noarch 0.9.6-6.fc25 @anaconda 251 k
Transaction Summary
========================================================================================================================================================================================
Remove 24 Packages
Installed size: 13 M
Is this ok [y/N]: y
(snip)
}}}
Anyway went ahead with that, and after, at least only the one is installed now.
{{{
$ rpm -qa | grep gdb-headless
gdb-headless-7.12-29.fc25.x86_64
}}}
Then proceeded with the full "dnf update", success!
---
So why the gdb-headless conflict in the first place? This was stumbled over via a fresh installation of Fedora 25. There must be some package dependency link broken, or what else?
(In reply to Fermulator from comment #6) > @Igore why "NOTABUG"? (1) It may be a bug of Component rpm, not dnf. One never knows. (2) rpm database with multiple versions of a package is a well known state but it is not a correct state. One needs to figure out why that happened which you did not provide information for. Apparently a previous update has aborted in the middle but we do not know why. (In reply to Fermulator from comment #7) > Anyway went ahead with that, You should not, there should be a way to remove duplicit rpm database entry without affecting other packages. But that is offtopic here. > So why the gdb-headless conflict in the first place? Because the rpm database contains two versions of one package. The problem is why did that happen. Not what happens with two versions of one package installed. > This was stumbled over via a fresh installation of Fedora 25. Obviously the fresh installation has not finished correctly. We do not know why. > There must be some package dependency link broken, or what else? No. Explained above. gdb moved manpages in a recent update, a carefully placed Conflicts: tag should resolve this. My bad, gdb.spec already included:
Requires: gdb-headless%{?_isa} = %{version}-%{release}
which should enforce that gdb and gdb-headless install matching version-release
I went ahead and added an explicit Conflicts too, which should catch any possible errors before rpm/dnf transactions start.
Nice Rex, that sounds great. (can I see the patch/diff out of curiosity?) (In reply to Fermulator from comment #11) > (can I see the patch/diff out of curiosity?) https://src.fedoraproject.org/cgit/rpms/gdb.git/ Although I do not understand why there should be Conflicts when there is already Requires. If it behaves better that way then it is a bug in dnf. |