Bug 151598 - Debug info RPMs do not "require" exact maching binary rpm
Debug info RPMs do not "require" exact maching binary rpm
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: redhat-rpm-config (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mike McLean
: Reopened
Depends On:
Blocks: 116894 173278 232803
  Show dependency treegraph
 
Reported: 2005-03-20 11:37 EST by Andrew Cagney
Modified: 2008-02-18 10:57 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-18 10:57:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Andrew Cagney 2005-03-20 11:37:42 EST
Problem:

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

Solution:

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 11:45:02 EST
See also bug #146957.
Comment 2 Paul Nasrat 2005-04-04 05:27:58 EDT
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 18:35:04 EDT
- 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 10:53:03 EDT
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 12:03:07 EDT
Evil macros:

%description\
%{?_enable_debug_packages:%{!?__debug_obsoletes:Obsoletes:
%{?epoch:%{epoch}:}%{name}-debuginfo < %{version}-%{release}}}\
%global __debug_obsoletes 1\
%%description%{nil}
Comment 9 Ville Skyttä 2006-01-25 14:45:46 EST
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 09:10:22 EST
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 06:40:47 EST
Created attachment 145790 [details]
base->debuginfo Conflicts based patch.

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

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 06:42:20 EST
Created attachment 145791 [details]
.src.rpm trivia fast debuginfo generating testing package.
Comment 13 Red Hat Bugzilla 2007-02-05 14:27:55 EST
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
Comment 14 Jan Kratochvil 2008-02-17 10:29:37 EST
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.