Description of problem: Bug 447520 requires inclusion of the Obsoletes tag for the debug (debuginfo) package. The current macros file(s) do not permit it. Version-Release number of selected component (if applicable): rpm-4.4.2.3-2.fc9.x86_64 redhat-rpm-config-9.0.2-1.fc9.noarch How reproducible: Always. Steps to Reproduce: 1. Put into your .spec file: %define _debug_package_tags Obsoletes: obsoleted-package 2. Patch /usr/lib/rpm/macros (and possibly /usr/lib/rpm/redhat/macros) by the attached fix. 3. rpmbuild -bb *.spec 4. rpm -q --requires -p *-debuginfo.x86_64.rpm Actual results: (nothing) Expected results: obsoleted-package Additional info: This Bug will need to be cloned for redhat-rpm-config if approved.
Created attachment 306227 [details] Insert new optional macro %{_debug_package_tags}.
FWIW, its likely easier process to manage if one implemented a different upgrade policy specifically for -debuginfo packages, say, always obsoleting foo-debuginfo-V-R when the foo-V-R is erased. That's likely 20-30 lines of C code in lib/depends.c, not hard at all. Adding a macro expansion to permit (under packager control) an optionally specified Obsoletes: when the package is built is sure to confuse packagers more than they already are wrto building -debuginfo packages. JMHO, YMMV, as always.
I agree it is a crude hack and I expect most of the Obsoletes cases will forget this debuginfo obsoletion. Just I do not find it so clear how it should behave otherwise - there can be multiple subpackages and even the basename package may not even exist (used for example for F9 openoffice.org). You may obsolete just one of the subpackages. And it is valid to have installed a debuginfo package without corresponding matching binary package (for example for remote debugging; it is not perfectly right as readonly code/data will not be available for the debugger in such case). So if you have installed A, A-X and A-debuginfo, you install new package B which obsoletes A and A-X you still cannot remove A-debuginfo as there may exist package A-Y residing on a remote host which I want to use A-debuginfo for. Which packages should get automatically removed/upgraded was discussed more in the unfixed Bug 432806 and it may or may not fall into the YUM scope.
Heh, all of -debuginfo generation is a very crude hack that becomes increasingly obscure and unmanageable. Reading #432806 you appear to want any -debuginfo packages that are installed to be maintained in sync with the set of executables in packages to which they are attached. That's a perfectly reasonable goal imho. And adding Obsoletes: to a package is the current mechanism by which package renaming is discovered by depsolvers, so the mechanism to add an Obsoletes: to -debuginfo is perfectly sound for the case of package renaming. However, you already are pointing out (in 3rd paragraph of comment #3) that -debuginfo can have different upgrade paths than other packages. Typically the Obsoletes: A in the new B package is used by depsolvers to discover that B needs to be installed as the replacement for A, in which case A-Y (in yr example) is typically obsoleted (and replaced by *some* new package even if that is not by the new set of B packages) as part of renaming the original set A to B. What is generally different about -debuginfo packages is that they are contextually dependent on the existence of other installed packages (like the examples from the set {A,A-X,A-Y} you have given). The relation is typically many-to-one because there's a single -debuginfo generated per build, even though there may be several sub-packages as in the set {A,A-X,A-Y}. An identifier/marker for the set {A,A-X,A-Y} that is known in the -debuginfo package is RPMTAG_SOURCERPM/RPMTAG_SOURCEPKGID (or even better add RPMTAG_SOURCEBUILDID to all packages produced by a build}. Once the members of the set {A,A-X,A-Y} and associated -debuginfo are known, then a contextually sensitive policy rule for erasing -debuginfo is easily expressed: Remove the -debuginfo when the last installed member of the set {A,A-X,A-Y} is removed. That policy rule handles the "out with the old" erasure portion of an upgrade as well, preserving the older -debuginfo if {A,A-X} but not A-Y are replaced because there is still a member of the set tied to the already installed -debuginfo. Another policy rule for the "in with the new" install portion of an upgrade is also easily expressed: Install the new -debuginfo package when any member of the set {A-A-X,A-Y} is upgraded, AND the -debuginfo for the set was previously installed. The odd corner case of having *only* the -debuginfo package installed for remote debugging is unaffected by either of the two policy rules just mentioned because no member of the set {A,A-X,A-Y} is installed, and so neither rule applies. That's the "different upgrade policy" that I suggested in fuller detail. Life with depsolvers like yum has 2 additional needs: 1) adding Obsoletes for -debuginfo package renaming discovery (that's the patch in this bug). 2) visibility of -debuginfo repositories, should -debuginfo repos be opt-in or opt-out? (that's my restatement of what I see in #432806). I can code up the above upgrade policy for -debuginfo in rpm by generating a rpmdb index for Sourcepkgid (buildid would be preferred but I haven't tried to add buildid to *.rpm metadata yet), and mebbe 20-30 lines of logic in lib/depends.c rpmtsAdd{Install,Erase}Element() if you are interested. I will likely do that @rpm5.org somewhen no matter what.
(In reply to comment #4) > However, you already are pointing out (in 3rd paragraph of comment #3) that > -debuginfo can have different upgrade paths than other packages. Typically > the Obsoletes: A in the new B package is used by depsolvers to discover that > B needs to be installed as the replacement for A, More the Provides tag says that but sure it depends on how the upgrade happens. > An identifier/marker for the set {A,A-X,A-Y} that is known in the -debuginfo > package is RPMTAG_SOURCERPM/RPMTAG_SOURCEPKGID (or even better add > RPMTAG_SOURCEBUILDID to all packages produced by a build}. I did not find RPMTAG_SOURCEBUILDID anywhere. I expect it is unrelated to: http://fedoraproject.org/wiki/Releases/FeatureBuildId > Once the members of the set {A,A-X,A-Y} and associated -debuginfo are known, Therefore -debuginfo should contain the list of subpackages "A,A-X,A-Y"? AFAIK currently there is no such information in -debuginfo rpm, right? > then a contextually sensitive policy rule for erasing -debuginfo is easily > expressed: > Remove the -debuginfo when the last installed member of the set {A,A-X,A-Y} is removed. Yes, such rule would be great! > Another policy rule for the "in with the new" install portion of an upgrade > is also easily expressed: > Install the new -debuginfo package when any member of the set {A-A-X,A-Y} > is upgraded, > AND > the -debuginfo for the set was previously installed. This is out of my rpm knowledge as automatic installation of packages is a rpm5+ feature. I may pinpoint the current YUM flaw with kernel debuginfos: If I have kernel-1.0 kernel-debuginfo-1.0 bash-1.0 and I do `yum update' it will say: Installing: kernel-2.0 Upgrading: kernel-debuginfo-2.0 bash-2.0 And I am left with kernel missing its debuginfo with the resulting packages: kernel-1.0 kernel-2.0 kernel-debuginfo-2.0 bash-2.0 I would expect more the style: Installing: kernel-2.0 kernel-debuginfo-2.0 Upgrading: bash-2.0 > Life with depsolvers like yum has 2 additional needs: > > 1) adding Obsoletes for -debuginfo package renaming discovery (that's the > patch in this bug). > 2) visibility of -debuginfo repositories, should -debuginfo repos be > opt-in or opt-out? (that's my restatement of what I see in #432806). IMO either opt-out or automatic opt-in/out if any -debuginfo is installed. > I can code up the above upgrade policy for -debuginfo in rpm by generating > a rpmdb index for Sourcepkgid (buildid would be preferred but I haven't tried > to add buildid to *.rpm metadata yet), and mebbe 20-30 lines of logic in > lib/depends.c rpmtsAdd{Install,Erase}Element() if you are interested. I will > likely do that @rpm5.org somewhen no matter what. Sure I would like to get it fixed, debuginfos should get more important soon (F10?) with the GCC debuginfo producer fixes by Alexandre Oliva. Just rpm vs. rpm5 is not my war so I unfortunately have to live with YUM now.
FYI: rpm5 has abrbitrary tags. Any string identifier is mapped to a 1Gb tagno spce using a SHA-1. But yes, RPMTAG_SOURCEBUILDID does not exist in rpom metadata yet. The tag will have exactly the value that is described at the URI you gave. There's little reason not to carry the build id in packages imho. No -debuginfo shouldn't contain the names, but rather a set identifier/marker, that allows the set of packages (including -debuginfo) to be enumerated and counted when necessary. I'm currently using RPMTAG_SOURCERPM as a "build set" identifier, will move to RPMTAG_SOURCEPKGID and/or RPMTAG_SOURCEBUILDID as my development progresses. What is needed (no matter whether yum or rpm) is well defined behavior and expectations for upgrading -debuginfo packages. I'm helping define that. Are kernel-debuginfo packages reasonably sized these days? Last I checked, duplicated symbol tables were leading to 500Mb kernel-debuginfo packages. If kernel-debuginfo packages are now reasonably sized, I will attempt to also address kernel-debuginfo issues. I suspect the erasure policy rule for -debuginfo I wrote will Just Work, but there may be a few more details needed. You will have to address yum issues through yum channels, all I can do is help identify the usage case for Obsoletes: and perhaps clarify the issue of opt-in/opt-out visibility. Meanwhile the -debuginfo package upgrade rules I outlined are certainly obvious and simple, and perhaps 30% implemented @rpm5.org already. I expect to have a completed implementation this weekend.
Automagic erasures of -debuginfo packages is now implemented @rpm5.org. Thanks for your comments.
And most of the install rule to block old -debuginfo erasure until all other packages with common *.src.rpm are erased is now also implemented. I say "most" because (as I have implemented) there is an implicit requirement that the attempted upgrade of the -debuginfo follows the upgrade of all other packages that came from the same *.src.rpm. Considering the other flaws (rewriting file paths in ELF headers in debugedit) that are laready present, that is "gud enuf" for @rpm5.org development. I'll shuffle the install/upgrade argv[] to ensure -debuginfo packages are last, or will split -debuginfo into its own transaction set if necessary; both of those approaches are viable solutions.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.