Bug 983029

Summary:	stale debuginfo packages remain installed
Product:	[openSUSE] openSUSE Tumbleweed	Reporter:	Olaf Hering <ohering>
Component:	Basesystem	Assignee:	Dominique Leuenberger <dimstar>
Status:	RESOLVED DUPLICATE	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	chcao, mls, zypp-maintainers
Version:	Current
Target Milestone:	---
Hardware:	All
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Olaf Hering 2016-06-03 13:06:13 UTC

openSUSE:Factory _product obsoletepackages.inc contains a list of packges which should be removed.
The given <pkg>-debuginfo remains installed. Whatever is responsible of removing pkgs from the obsoletepackages list should also take care of -debuginfo.
Instead of 'rpm -e <pkg>', do 'rpm -e <pkg> <pkg>-debuginfo' (or whatever is used internally).

Comment 1 Chenzi Cao 2016-06-19 11:19:09 UTC

Hi Dominique, would you like to take a look at this issue? Thank you!

Comment 2 Dominique Leuenberger 2016-06-19 11:28:00 UTC

-debuginfo packages are not part of the 'regular ftp tree' and/or product and are thus not handled by the obsoletes handlers

AFAIR, zypper dup used to have a flag to remove stale packages that no longer exist in any configured repository...

@zypp maintainers: is still no longer the case?

Comment 3 Michael Andres 2016-06-20 09:04:10 UTC

Orphaned packages that no longer exist in any configured repository are silently removed IF they are involved in a conflict. So if a -debuginfo is not tied to it's package dependency wise, it might indeed stay.

Zypper can probably offer a 'dup --drop-orphaned' which would of course affect ALL orphaned packages (manually installed, OneKick install, etc.), so one should use it with care.

Comment 4 Michael Schröder 2016-06-20 09:09:29 UTC

Nah, the solution is to add back the requires to the main package. But this will only work if the solver knows that it can deinstall debuginfo packages without asking for permission. (i.e. we must not generate an "update rule" for them.)

Anyway, dup of bug 658212...

*** This bug has been marked as a duplicate of bug 658212 ***