Bug 151598 - Debug info RPMs do not "require" exact maching binary rpm
Summary: Debug info RPMs do not "require" exact maching binary rpm
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: redhat-rpm-config
Version: 4.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Mike McLean
QA Contact:
Depends On:
Blocks: 116894 173278 232803
TreeView+ depends on / blocked
Reported: 2005-03-20 16:37 UTC by Andrew Cagney
Modified: 2008-02-18 15:57 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-02-18 15:57:17 UTC
Target Upstream Version:

Attachments (Terms of Use)
base->debuginfo Conflicts based patch. (528 bytes, patch)
2007-01-17 11:40 UTC, Jan Kratochvil
no flags Details | Diff
.src.rpm trivia fast debuginfo generating testing package. (2.10 KB, application/octet-stream)
2007-01-17 11:42 UTC, Jan Kratochvil
no flags Details

Description Andrew Cagney 2005-03-20 16:37:42 UTC

People keep installing a debuginfo RPM that doesn't match the installed binary
RPM, and then wonder why GDB refuses to use that debug info (GDB should also
complain about the screwup, but thats past the event).


The debug RPMs do not "require" that the correct corresponding binary is installed.

For instance:

$ rpm -qpR at-debuginfo-3.1.8-64_EL.ppc.rpm
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1

it should also specify that it requires:

   at == 3.1.8-64_EL

which is provided by the corresponding binary rpm:

rpm -qp --provides at-3.1.8-64_EL.ppc.rpm
config(at) = 3.1.8-64_EL
at = 3.1.8-64_EL

Comment 1 Andrew Cagney 2005-03-20 16:45:02 UTC
See also bug #146957.

Comment 2 Paul Nasrat 2005-04-04 09:27:58 UTC
If at-debuginfo requires at = %{version}-%{release}, then an update to at without
at-debuginfo causes a missing requirement and will pevent updating. Potentially
leaving a vulnerable package around on the system

Not all repositories for fedora carry debuginfo packages - for RHEL I'd need to
confirm that we guarantee that -debuginfo is in RHN before this change, we'd
also need it in redhat-rpm-config too.

Comment 5 Andrew Cagney 2005-04-04 22:35:04 UTC
- our support organization is supplying customers with debuginfo RPMs; so RHN or
not we've got customers hitting this problem.

- the dependency should be:  foo-debug requires foo; and not foo requires
foo-debug.  That way, having foo installed doesn't force foo-debug to be
installed.  This is identical to glibc-devel requiring glibc, but not the reverse.

- a system with a mismatched debuginfo rpm is in an inconsistent state.  We
should not be allowing customers to do that to their system.

- as for updates, the customer should remove the debuginfo rpm before doing the
update (or get a newer one)

(outside the box, you could have RPM N+1 obsolete RPM-debuginfo N)

Comment 7 Andrew Cagney 2005-04-05 14:53:03 UTC
BTW, an update, without matching debug info, breaks debug functionality (leaving
the system in an inconsistent state) - no need to remove the debuginfo.  On the
other hand, if the broken debug info is removed, the system is kept consistent
and it's clear that a new debuginfo rpm is required.

Comment 8 Paul Nasrat 2005-04-05 16:03:07 UTC
Evil macros:

%{?epoch:%{epoch}:}%{name}-debuginfo < %{version}-%{release}}}\
%global __debug_obsoletes 1\

Comment 9 Ville Skyttä 2006-01-25 19:45:46 UTC
Note that the "main" %{name} package doesn't necessarily exist in all cases, so
a simplistic "Requires: %{name}<whatever>" for all -debuginfos doesn't work.

Comment 10 Jeff Johnson 2006-03-01 14:10:22 UTC
rpm does not enable -debuginfo production by default, so this is a redhat-rpm-config, not rpm, problem.

Comment 11 Jan Kratochvil 2007-01-17 11:40:47 UTC
Created attachment 145790 [details]
base->debuginfo Conflicts based patch.

# FIXME: It will never get satisfied with appended: .%{_target_cpu}
Conflicts: %{?epoch:%{epoch}:}%{name}-debuginfo < %{version}-%{release}\
Conflicts: %{?epoch:%{epoch}:}%{name}-debuginfo > %{version}-%{release}}\

It goes the opposite way.  If we cannot `debuginfo Requires basepackage=verrel'
we can `basepackage Conflicts debuginfo<>verrel'.
It will limit the installation of multiple versions of debuginfos but such case
IMO does not need to be supported.
It may require user interaction (`rpm -e *.debuginfo') in the case the
appropriate upgraded debuginfos are currently not available.  It was an
intention (over `Obsoletes' methods) as the user should be notified if he is
going to lose the manually installed debuginfos before - users installing
debuginfos are not completely dumb to cannot type `rpm -e' anyway.

Comment 12 Jan Kratochvil 2007-01-17 11:42:20 UTC
Created attachment 145791 [details]
.src.rpm trivia fast debuginfo generating testing package.

Comment 13 Red Hat Bugzilla 2007-02-05 19:27:55 UTC
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.

Comment 14 Jan Kratochvil 2008-02-17 15:29:37 UTC
The arch FIXME part of the Comment 11 is the (upstream fixed) rpm Bug 235755.

Forbidding installation of non-matching PKG and PKG-debuginfo versions is wrong
as in the future (F10) we should have multi debuginfo versions installed.

Therefore moved this problem to YUM as described in Bug 432806 Comment 8.

This Bug should get WONTFIXed.

Note You need to log in before you can comment on or make changes to this bug.