Bug 432806 - `yum update' gets the installed debuginfos out of sync
`yum update' gets the installed debuginfos out of sync
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
: Reopened
: 483914 (view as bug list)
Depends On:
Blocks: 1208769
  Show dependency treegraph
 
Reported: 2008-02-14 09:58 EST by Matěj Cepl
Modified: 2015-04-03 02:46 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-04 09:19:48 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)

  None (edit)
Description Matěj Cepl 2008-02-14 09:58:39 EST
Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:
I am a bugmaster of the all gecko files. We have bugs where reporter when asked
for stacktrace, even when using debuginfo-install produces back with missing
debuginfo information.

See bug 431162 comment 13 for an example.

Steps to Reproduce:
1. ask reporter for backtrace from firefox and explain them how to get debuginfo
information
2.wait for their response
3.
  
Actual results:
plenty of missing debuginfo information

Expected results:
useful backtrace (even when poor reporter has to install tons of -debuginfo
packages)
Comment 1 Seth Vidal 2008-02-14 10:10:30 EST
need more info. What packages is it that debuginfo-install didn't get?

Is there a heuristic to them? 
Comment 2 Matěj Cepl 2008-02-15 08:27:17 EST
Take a look at the attachment 294191 [details] (linked to the comment I referred to) --
/usr/lib/xulrunner-1.9pre/libxul.so debuginfo information is missing.
Comment 3 Jan Kratochvil 2008-02-15 08:28:47 EST
IMO this problem is a DUPLICATE of either:
Bug 151598: Debug info RPMs do not "require" exact maching binary rpm
 - so that the users do not have the matching debuginfo version installed.
 (patch provided with no feedback)
and/or 
Bug 235755: rpm doesn't allow 'Requires: foo.%{ARCH}'
 - so that the x86_64 requirements get falsely satisfied by the i386 packages.
 (fixed upstream but Rawhide still does not have the backport)

(Bug 427579 is also ugly for any user acceptable debuginfos handling)

To make the problem solvable/reproducible it would be best to get from the
target system first:
  rpm -qa --qf '%{name}-%{version}-%{release}.%{arch}\n'
to be aware what in fact is the problem there.
Comment 4 Matěj Cepl 2008-02-15 08:36:49 EST
Setting NEEDINFO on myself, and waiting for satysfying other NEEDINFO in bug
431162 comment 19 
Comment 5 Andrew Farris 2008-02-16 23:20:36 EST
Matej I thought I'd comment on this here, small issue with getting the firefox
and xulrunner debuginfo sync'd up right now on i686.  This does not happen on
x86_64 when doing main arch only.

Updating:
 firefox                 i386       3.0-0.beta3.21.nightly20080214.fc9 
development       1.4 M
 firefox-debuginfo       i386       3.0-0.beta3.21.nightly20080214.fc9 
development-debuginfo  625 k
 xulrunner               i386       1.9-0.beta3.22.nightly20080215.fc9 
development       9.5 M
 xulrunner-debuginfo     i386       1.9-0.beta3.22.nightly20080215.fc9 
development-debuginfo   64 M

Transaction Check Error:
  file /usr/src/debug/mozilla/memory/jemalloc/jemalloc.c conflicts between
attempted installs of firefox-debuginfo-3.0-0.beta3.21.nightly20080214.fc9.i386
and xulrunner-debuginfo-1.9-0.beta3.22.nightly20080215.fc9.i386

I attached a new backtrace with matched x86_64 debuginfo to bug# 431162
Comment 6 Matěj Cepl 2008-02-17 02:21:59 EST
Jan, the requested information is attachment 295021 [details]
Comment 7 Matěj Cepl 2008-02-17 02:23:55 EST
Sorry, I meant the attachment 295039 [details] (on i386) and the attachment 295040 [details] (on
x86_64).

Comment 8 Jan Kratochvil 2008-02-17 10:24:50 EST
The debuginfo problem part in Bug 431162 was due to debuginfo rpms out of sync.
The user did `debuginfo-install APPNAME' but later `yum update' commands did no
longer update the associated debuginfos.

rpm currently permits installing PKG-2.rpm together with PKG-debuginfo-2.rpm.
I was attempting to disallow such state in Bug 151598 but it is no longer wanted
behavior:
In future (F10) we should have the possibility of simultaneously installed:
  PKG-debuginfo-1.rpm
  PKG-debuginfo-2.rpm
(draft patches at http://people.redhat.com/jkratoch/multidebug/ ).

=>

I would like yum (not yum-utils) to automatically:
If it is UPDATING PKG from version 1 to 2 it should:
 - Check if PKG-debuginfo-1 is installed and if it is then:
    * enable the -debuginfo repos for enabled primary repos
    * UPDATE PKG-debuginfo from version 1 to explicitely version 2
       - Do not update to version 3 even if it would be available.
       - PKG-debuginfo-2 should exist, not sure what to do if it does not.
 - Do not care of the other versions of PKG-debuginfo installed.
(probably) if it is REMOVING PKG of version 1, remove also PKG-debuginfo-1
 - Do not care of the other versions of PKG-debuginfo installed.

I am not so Python friendly, do you have a requirement for a patch?
Thanks.
Comment 9 Jan Kratochvil 2008-02-17 10:43:43 EST
(In reply to comment #5)
> Transaction Check Error:
>   file /usr/src/debug/mozilla/memory/jemalloc/jemalloc.c conflicts between
> attempted installs of firefox-debuginfo-3.0-0.beta3.21.nightly20080214.fc9.i386
> and xulrunner-debuginfo-1.9-0.beta3.22.nightly20080215.fc9.i386

This packaging problem was cloned into Bug 433200.
Comment 10 Seth Vidal 2008-02-18 13:26:09 EST
in response to comment #8. I don't see it happening. Enabling repos based upon
what we see is installed is doing more thinking for the user than I  think they
want. If the user doesn't specify the repos they want, then they don't get those
repos. That's really all there is to it.

I'm sorry.
Comment 11 Matěj Cepl 2008-02-18 14:51:03 EST
Seth, you have certainly point — we don’t want to make Microsoft Bob. Right. On
the other hand, I would really need 100% foolproof method how to get all my
reporters to get fully working debuginfo information. So, couldn’t we have
something like --debuginfo parameter to yum install?

Wait, we have it, that’s what debuginfo-install is all about! However, that
doesn’t work well — that’s what this bug is about! I don’t understand well,
what’s the problem, but I am quite sure, that when reporter runs
debuginfo-install, she *wants* all debuginfo to be installed, whether that means
enabling debuginfo repositories or not.

So, why it doesn’t work?
Comment 12 Matěj Cepl 2008-02-18 14:54:43 EST
Or should I just warn reporters that after using debuginfo-install they should
immediately run gdb and provide the information I asked them to provide, before
the next yum upgrade will screw their *-debuginfo pacakages?

Jan, will getting backtraces immediately after running debuginfo-install provide
foolproof method of getting all debuginfo resolved?
Comment 13 James Antill 2008-02-18 15:48:10 EST
 Yes, if the packaging is done properly then yum will warn the users that the
debuginfo rpms will be removed if they do the upgrade (if this isn't happening
it's a bug somewhere).

 At which point the user will make the choice for what do to (including enabling
the debuginfo repos, and everything doing the right thing) -- yum-aliases
already has the ad. hoc. DBG/SRC aliases to do this for Fedora GA/updates repos.
We could do a real plugin for the same --dbgrepos and --srcrepos? But I'm not
sure we'd want this in the default yum command, and Seth probably has an even
stronger opinion on that.

 It's also possible for us to have something like:

debuginfo-install --enablerepos blah

...where it would install the debuginfo rpms for blah (and it's deps) but also
enable the debuginfo repos. Getting them turned off again doesn't have an
obvious UI though, and given that this would push pain onto the users I'm not
sure it's the correct approach.
Comment 14 James Antill 2008-02-18 16:05:48 EST
 Ok, so I was confused ... if the deps. are correct yum won't remove things
automatically ... it just won't update the affected pkgs (unless the user
manually remove the -debuginfo variants). But that's roughly the same end result
... working deps + debuginfo-install == debug info is there for gdb.
Comment 15 Seth Vidal 2008-02-19 01:46:45 EST
(In reply to comment #11)

> So, why it doesn’t work?

Here is what's happening.

A user encounters a problem and is told to debuginfo-install the packages for
the software in question.

debuginfo-install installs debuginfo packages for the package(s) specified and
all of their immediate dependencies.

Afaik this works correctly and as designed.

The trouble is that the user then performs an update and the debuginfo files no
longer match up. So the user needs to run debuginfo-install that package name,
again, so they get the most recent debuginfo packages that match with the binary
packages they are actively running.

Now, your question is - why, after running debuginfo-install, are debuginfo
repositories not defaulting to on. The reason is simple, the user doesn't want
them on all the time. They only want them on when they are needed. A user does
not want to download metadata updates for the debuginfo repositories b/c
excluding the exceptional debug cases they never use them and they just waste
bandwidth and diskspace.

Does that explain why we don't turn them on automatically?

if a user wants to update all of their debuginfo packages in one command, run this:

yum --enablerepo='*-debuginfo' update

This still isn't a bug here afaict.

Comment 16 Matěj Cepl 2008-02-19 01:58:23 EST
So, is my comment 12 good enough answer for my purposes?
Comment 17 Jan Kratochvil 2008-02-19 03:41:12 EST
(In reply to comment #13)
>  Yes, if the packaging is done properly then yum will warn the users that the
> debuginfo rpms will be removed if they do the upgrade (if this isn't happening
> it's a bug somewhere).

No, because having PKG-1.rpm with PKG-debuginfo-2.rpm is a valid state if one is
analysing a core file from remote system where PKG-2.rpm is installed.  Or
debugging PKG-2 remotely or running systemtap for remote kernel etc.
I wrote these reasons in the Comment 8.

So there cannot be the rpm hard Requires/Conflicts restrictions.
Still there should be some soft "Recommends" (present in .deb, not in .rpm) so
that in the most common UPDATE case the debuginfos already matching the
installed versions get updated along.

(In reply to comment #14)
>  Ok, so I was confused ... if the deps. are correct yum won't remove things
> automatically ... it just won't update the affected pkgs (unless the user
> manually remove the -debuginfo variants).

Please see above.

(In reply to comment #15)
> Now, your question is - why, after running debuginfo-install, are debuginfo
> repositories not defaulting to on. The reason is simple, the user doesn't want
> them on all the time.

This is not about "all the time".  Most of the people will never have any
debuginfo packages installed and therefore debuginfo repositories do not get
enabled.

The moment YUM updates PKG-1 to PKG-2 and does NOT update the installed
PKG-debuginfo-1 to PKG-debuginfo-2 a problem happened.  The solution
possibilities are:

(1) Refuse debuginfo-install if the debuginfo repositories are not enabled.

(2) Enable the debuginfo repositories ONLY IF we find the problem is going to
    happen - if we found we are updating PKG-1 but PKG-debuginfo-1 is installed.
    This was suggested in the Comment 8.

(?) More?

> They only want them on when they are needed.

Yes, I agree, therefore I was proposing the point (2) or Comment 8 above.

> A user does not want to download metadata updates for the debuginfo
> repositories b/c excluding the exceptional debug cases they never use them
> and they just waste bandwidth and diskspace.

Right, in such case the debuginfo repositories would never get enabled according
to the point (2) or Comment 8 above.

> if a user wants to update all of their debuginfo packages in one command,

People want to update their system - they forgot they installed some debuginfo
packages before.

> run this:
> 
> yum --enablerepo='*-debuginfo' update

But the real world users do not do it - please see the Bug 431162 for an example.
Comment 18 Seth Vidal 2008-03-14 11:10:01 EDT
What if debuginfo-install grew an 'update' option?

Then you could ask users to make sure all of their debuginfo files are updated
when it is necessary.
Comment 19 Jan Kratochvil 2008-03-14 13:54:07 EDT
(In reply to comment #18)
> What if debuginfo-install grew an 'update' option?
> 
> Then you could ask users to make sure all of their debuginfo files are updated

It must be automatic.  System with debuginfos out of sync is broken.

> when it is necessary.

It is always necessary when the debuginfos are installed.  Otherwise they must
get uninstalled.
Comment 20 Bug Zapper 2008-05-14 01:12:07 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 21 Will Woods 2008-05-30 12:44:36 EDT
debuginfo files should be considered temporary. If you really need them to be
kept up-to-date, enable the debuginfo repo(s).

By default, we should delete out-of-date debuginfo files periodically. Or delete
them after yum upgrades.
Comment 22 Jan Kratochvil 2008-05-30 12:51:34 EDT
Yes, the Comment 21 looks fine even for me.
Comment 23 Jan Kratochvil 2008-05-30 15:22:04 EDT
Just a heads up for the rpm5.org implementation in Bug 447708 Comment 7.
I have not tried it, though.
Comment 24 seth vidal 2009-01-21 13:18:42 EST
We can add a yum-util (or an option to debuginfo-install) to clean out old debuginfo pkgs.

Any preferences?
Comment 25 James Antill 2009-01-21 16:30:52 EST
debuginfo-install --cleanup, would probably be my first guess
Comment 26 Jan Kratochvil 2009-01-21 17:55:59 EST
I did a testcase run for the Joe user:
1:I have coreutils-6.12-17.fc10.x86_64 installed.
2:I run: gdb /bin/echo
3:I am told and so run: 
  Missing separate debuginfos, use: 
    debuginfo-install coreutils-6.12-17.fc10.x86_64
4:GDB works now.
5:I do (with default *.repo using -debuginfo repos disabled): yum -y update
6:Now I get installed: 
  coreutils-6.12-18.fc10.x86_64 
  coreutils-debuginfo-6.12-17.fc10.x86_64.rpm
7:I run: gdb /bin/echo
8:I am told and so run: 
  Missing separate debuginfos, use: 
    debuginfo-install coreutils-6.12-18.fc10.x86_64
  Please note debuginfo-install does correctly an update here instead of a new
  installation that would cause two simultaneous debuginfo pkgs conflicts.
9:GDB works now.

In fact there is nothing too much serious, if one follows the advices it works.

Just in point 6 we have a useless debuginfo package installed.  So the point 5 should either
(a) Remove the no longer valid debuginfo packages or
(b) Update the debuginfo packages out of sync.

Not asking for any explicit option as the Joe user will never use such one.
Comment 27 seth vidal 2009-02-02 10:13:50 EST
I sounds like from comment 26 that we should close this notabug

agreed?
Comment 28 Jan Kratochvil 2009-02-02 10:25:03 EST
Not agreed.  It is a real yum or rpm bug although I agree a lower priority one (and it is now already `low').
Comment 29 seth vidal 2009-02-02 10:35:22 EST
I guess I'm confused, then. What's the requested course of action?
Comment 30 Jan Kratochvil 2009-02-03 03:13:45 EST
Already requested in Comment 8 and Comment 17 (2):
If it is UPDATING PKG from version 1 to 2 it should:
 - Check if PKG-debuginfo-1 is installed and if it is then:
    * enable the -debuginfo repos for enabled primary repos
    * update PKG-debuginfo from version 1 to explicitely version 2
Comment 31 Will Woods 2009-02-03 10:26:59 EST
This is not a bug.

The problem you're having is this: You want debuginfo packages to be updated along with the rest of the system. As mentioned in comment #21, this is a solved problem: just enable the debuginfo repos. 

The behavior you're asking for is exactly the same, except you want it to work *without* enabling the repos. That's just silly. Enable the repos if you want debuginfo kept up to date!

A more useful solution would be to write a yum plugin that *removes* out-of-date debuginfo packages when their parent packages are removed.

So make this an RFE for that yum plugin, or close NOTABUG.
Comment 32 Jan Kratochvil 2009-02-03 10:38:44 EST
(In reply to comment #31)
> The problem you're having is this: You want debuginfo packages to be updated
> along with the rest of the system. As mentioned in comment #21, this is a
> solved problem: just enable the debuginfo repos. 

The problem is that debuginfo-install will install the new -debuginfo packages WITHOUT having to enable the debuginfo repos.

If the requirement for a working system with any -debuginfo installed is to enable debuginfo repos then: debuginfo-install should refuse to run until the user enables the debuginfo repos.


> A more useful solution would be to write a yum plugin that *removes*
> out-of-date debuginfo packages when their parent packages are removed.

From the user POV:
(1) I have a longterm crashing problem with pidgin: debuginfo-install pidgin
(2) Debugging it with upstream, sending sometimes bugreports them, it still
    sometimes crashes.  (Based on my own experience.)
(3) As the time goes sometimes I / PackageKit do `yum update'.
(4) Now I found the debuginfos for pidgin are either out-of-sync or missing.

Why?  I have never run any debuginfo-remove command.

debuginfo package is a first class citizen, nothing which can be quietly removed.
Comment 33 James Antill 2009-02-03 11:11:58 EST
 Ok, yum-plugin-auto-update-debuginfo added upstream:

http://yum.baseurl.org/gitweb?p=yum-utils.git;a=commitdiff;h=ce873c479506dd4847e6c1c90c08516b2315d848
Comment 34 Jan Kratochvil 2009-02-03 12:02:00 EST
Works fine, thanks!
Comment 35 seth vidal 2009-02-04 09:20:02 EST
*** Bug 483914 has been marked as a duplicate of this bug. ***
Comment 36 Kamil Dudka 2009-12-25 15:18:01 EST
It seems like the problem persists in rawhide. Look at bug 548311 and bug 550516. Not sure if it is a bug of yum for now...

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