Bug 151598

See also bug #146957.

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.

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

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.

Evil macros:

%description\
%{?_enable_debug_packages:%{!?__debug_obsoletes:Obsoletes:
%{?epoch:%{epoch}:}%{name}-debuginfo < %{version}-%{release}}}\
%global __debug_obsoletes 1\
%%description%{nil}

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.

rpm does not enable -debuginfo production by default, so this is a redhat-rpm-config, not rpm, problem.

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.

Created attachment 145791 [details]
.src.rpm trivia fast debuginfo generating testing package.

REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.

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.