[Bug 658212] New: Need a way to garbage collect old -debuginfo packages
https://bugzilla.novell.com/show_bug.cgi?id=658212 https://bugzilla.novell.com/show_bug.cgi?id=658212#c0 Summary: Need a way to garbage collect old -debuginfo packages Classification: openSUSE Product: openSUSE 11.4 Version: Factory Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: libzypp AssignedTo: zypp-maintainers@forge.provo.novell.com ReportedBy: rguenther@novell.com QAContact: qa@suse.de CC: mls@novell.com Found By: --- Blocker: --- To avoid isses like bnc#657258 we need a way to tie a X-debuginfo package to the same version of X. The effect should be that X will be still updated even if X-debuginfo isn't available for the new version, in which case X-debuginfo should be deinstalled without user interaction. All X-debuginfo packages provide things like debuginfo(build-id) = 81a516dd2fc2ac4465408f6302359a201a94f0ee and so can easily be identified that way. X-debuginfo would get an additional Requires: X = %version-%release to tie both together and libzypp would have the additional knowledge that removing X-debuginfo is always a valid solution when updating/downgrading X. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=658212 https://bugzilla.novell.com/show_bug.cgi?id=658212#c1 Elmar Stellnberger <estellnb@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |estellnb@gmail.com --- Comment #1 from Elmar Stellnberger <estellnb@gmail.com> 2010-12-17 13:12:05 UTC --- Good proposal! Getting wrong backtraces is somewhat hazardous (I guess 97% of all developers would never think of a version mismatch of debuginfo packages if the backtrace simply does not seem to point to anything useful.). Nonetheless I would alltheleastwisemore desire longstandingly that the information for which packages debuginfo is needed and desired will be kept in some way. This could be by actually killing the debuginfo from the file system but leaving it in the package database (as the unmatching debuginfo would have been installed by an rpm -ivh --excludepath /). Sorting out for which packages to install debuginfo is a rather tedious task and can not be repeated on each upgrade/date. That way I would also welcome some user support in installing debuginfos (Bug 539723). Also please think of simply compiling the debuginfo in; at least for the core packages and some critical components like Xorg (similar proposal for KDE, see: Bug 237741). If we can have that for KDE why shouldn`t we do it this way for Xorg, libc and the system core, especially if no other solution appears to imaginable at the moment to bug 657258 and others? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=658212 https://bugzilla.novell.com/show_bug.cgi?id=658212#c2 Bernhard Wiedemann <bwiedemann@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bwiedemann@novell.com --- Comment #2 from Bernhard Wiedemann <bwiedemann@novell.com> 2011-02-20 09:46:36 CET --- I do not know, if any code was done in this direction, but you might want to open an entry on https://features.opensuse.org/ see also https://features.opensuse.org/308138 you might also find useful my one-liner to install needed debuginfo grep zypp /tmp/gdb.log|perl -pe "s/Try: //; s/install/-n $&/" | sh -x -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=658212 https://bugzilla.novell.com/show_bug.cgi?id=658212#c3 Richard Guenther <rguenther@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |johannesobermayr@gmx.de --- Comment #3 from Richard Guenther <rguenther@novell.com> 2011-08-26 07:17:20 UTC --- *** Bug 707731 has been marked as a duplicate of this bug. *** http://bugzilla.novell.com/show_bug.cgi?id=707731 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=658212 https://bugzilla.novell.com/show_bug.cgi?id=658212#c4 --- Comment #4 from Richard Guenther <rguenther@novell.com> 2011-08-26 07:18:12 UTC ---
From bnc#707731 some more thoughts:
There needs to be a way to specify that the %name-debuginfo package is less important than %name. Dependent on system-wide setting an update should 1) remove %name-debuginfo on update. Usually you have debugged a problem and the debuginfo is now stale, no need to update it. 2) update both packages, if %name-debuginfo is not available, remove it without asking Also when removing %name, %name-debuginfo should be automatically removed as well, this isn't achieved either. I don't think the above can be achieved using rpm dependencies in any way. Thus the only reasonable thing is to provide a link from %name-debuginfo to %name to relate them and have the solver and/or the package install frontend do the above magic manually. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=658212 https://bugzilla.novell.com/show_bug.cgi?id=658212#c5 --- Comment #5 from Johannes Obermayr <johannesobermayr@gmx.de> 2011-08-26 09:23:41 UTC --- (In reply to comment #4)
From bnc#707731 some more thoughts: I don't think the above can be achieved using rpm dependencies in any way. Thus the only reasonable thing is to provide a link from %name-debuginfo to %name to relate them and have the solver and/or the package install frontend do the above magic manually.
And that's exactly why we need a 'Requires: %name = %version-%release'. 'zypper (d)up' and 'yast2 --install' already ask what do with the non-fulfilled dependency (see my comment in bnc#707731): Example with https://build.opensuse.org/request/show/79821 applied: Basis: envytools-20110825.0522-1.1 and envytools-debuginfo-20110825.0522-1.1 are installed #envytools-20110825.0522-1.2.x86_64.rpm is not in the path zypper in ./envytools-debuginfo -20110825.0522-1.2.x86_64.rpm Loading repository data... Reading installed packages... Resolving package dependencies... Problem: nothing provides envytools = 20110825.0522-1.2 needed by envytools-debuginfo-20110825.0522-1.2.x86_64 Solution 1: do not install envytools-debuginfo-20110825.0522-1.2.x86_64 Solution 2: break envytools-debuginfo by ignoring some of its dependencies #envytools-debuginfo-20110825.0522-1.2.x86_64.rpm is in the path zypper in ./envytools-20110825. 0522-1.2.x86_64.rpm Loading repository data... Reading installed packages... Resolving package dependencies... The following packages are going to be upgraded: envytools envytools-debuginfo #envytools-debugino-20110825-0522-1.2.x86_64.rpm is in the path zypper in ./envytools-20110825.0522-1.1.x86_64.rpm Loading repository data... Reading installed packages... The selected package 'envytools-20110825.0522-1.1.x86_64' from repository 'Plain RPM files cache' has lower version than the installed one. Use 'zypper install --fo rce envytools-20110825.0522-1.1.x86_64' to force installation of the package. Resolving package dependencies... Nothing to do. #envytools-debuginfo-20110825.0522-1.1.x86_64.rpm is not in the path zypper in --force ./envytools-20110825.0522-1.1.x86_64.rpm Loading repository data... Reading installed packages... Forcing installation of 'envytools-20110825.0522-1.1.x86_64' from repository 'Plain RPM files cache'. Resolving package dependencies... Problem: envytools-debuginfo-20110825.0522-1.2.x86_64 requires envytools = 20110825.0522-1.2, but this requirement cannot be provided Solution 1: deinstallation of envytools-debuginfo-20110825.0522-1.2.x86_64 Solution 2: do not install envytools-20110825.0522-1.1.x86_64 Solution 3: break envytools-debuginfo by ignoring some of its dependencies So I cannot understand your worries - openSUSE's frontends can handle such things. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=658212 https://bugzilla.novell.com/show_bug.cgi?id=658212#c6 --- Comment #6 from Richard Guenther <rguenther@novell.com> 2011-08-26 09:39:51 UTC --- (In reply to comment #5)
(In reply to comment #4)
From bnc#707731 some more thoughts: I don't think the above can be achieved using rpm dependencies in any way. Thus the only reasonable thing is to provide a link from %name-debuginfo to %name to relate them and have the solver and/or the package install frontend do the above magic manually.
And that's exactly why we need a 'Requires: %name = %version-%release'.
No, we don't. A 'Requires: %name = %version-%release' does not merely link the packages but constitutes a bogus fact that the %name-debuginfo package requires %name in any form which it does not! I can perfectly well install _only_ a debuginfo package and inspect its contents, or use it from gdb when inspecting a core file. Thus, a requires is _wrong_. You could maybe say that it conflicts with %name != %version-%release but even that would be wrong in the core file case (where I want to be able to install a specific -debuginfo package, which is even suggested by gdb(!), without eventually needing to downgrade/upgrade my systems library packages).
'zypper (d)up' and 'yast2 --install' already ask what do with the non-fulfilled dependency (see my comment in bnc#707731):
Example with https://build.opensuse.org/request/show/79821 applied: Basis: envytools-20110825.0522-1.1 and envytools-debuginfo-20110825.0522-1.1 are installed
#envytools-20110825.0522-1.2.x86_64.rpm is not in the path zypper in ./envytools-debuginfo -20110825.0522-1.2.x86_64.rpm Loading repository data... Reading installed packages... Resolving package dependencies...
Problem: nothing provides envytools = 20110825.0522-1.2 needed by envytools-debuginfo-20110825.0522-1.2.x86_64 Solution 1: do not install envytools-debuginfo-20110825.0522-1.2.x86_64 Solution 2: break envytools-debuginfo by ignoring some of its dependencies
#envytools-debuginfo-20110825.0522-1.2.x86_64.rpm is in the path zypper in ./envytools-20110825. 0522-1.2.x86_64.rpm Loading repository data... Reading installed packages... Resolving package dependencies...
The following packages are going to be upgraded: envytools envytools-debuginfo
#envytools-debugino-20110825-0522-1.2.x86_64.rpm is in the path zypper in ./envytools-20110825.0522-1.1.x86_64.rpm Loading repository data... Reading installed packages... The selected package 'envytools-20110825.0522-1.1.x86_64' from repository 'Plain RPM files cache' has lower version than the installed one. Use 'zypper install --fo rce envytools-20110825.0522-1.1.x86_64' to force installation of the package. Resolving package dependencies...
Nothing to do.
#envytools-debuginfo-20110825.0522-1.1.x86_64.rpm is not in the path zypper in --force ./envytools-20110825.0522-1.1.x86_64.rpm Loading repository data... Reading installed packages... Forcing installation of 'envytools-20110825.0522-1.1.x86_64' from repository 'Plain RPM files cache'. Resolving package dependencies...
Problem: envytools-debuginfo-20110825.0522-1.2.x86_64 requires envytools = 20110825.0522-1.2, but this requirement cannot be provided Solution 1: deinstallation of envytools-debuginfo-20110825.0522-1.2.x86_64 Solution 2: do not install envytools-20110825.0522-1.1.x86_64 Solution 3: break envytools-debuginfo by ignoring some of its dependencies
So I cannot understand your worries - openSUSE's frontends can handle such things.
"handle" by asking the user. But then there is no way to make my above use-cases work with that requirement encoded in the package. So, no, I think adding a requires is a step in the completely wrong direction. Btw, see the initial description on how existing tools can link %name and %name-debuginfo (if not simply looking at the package name only). I think this -debuginfo stuff is purely a frontend issue, apart from maybe providing a more reliable link from %name-debuginfo to %name (you can add a Provides: debuginfo(pkg) = %name or similar). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=658212 https://bugzilla.novell.com/show_bug.cgi?id=658212#c7 --- Comment #7 from Johannes Obermayr <johannesobermayr@gmx.de> 2011-08-26 12:44:22 UTC --- (In reply to comment #6)
No, we don't. A 'Requires: %name = %version-%release' does not merely link the packages but constitutes a bogus fact that the %name-debuginfo package requires %name in any form which it does not! I can perfectly well install _only_ a debuginfo package and inspect its contents, or use it from gdb when inspecting a core file.
Thus, a requires is _wrong_. You could maybe say that it conflicts with %name != %version-%release but even that would be wrong in the core file case (where I want to be able to install a specific -debuginfo package, which is even suggested by gdb(!), without eventually needing to downgrade/upgrade my systems library packages).
For joe user %name and %name-debuginfo should have the same %version-%release. An advanced user (e. g. tester, developer) should know how (s)he can go around a dependency issue and install a %name-debuginfo package with different version. (e. g. via 'rpm -ihv --force --nodeps [--oldpackage] %name-debuginfo-${different_version}') an equivalent thing (--nodeps) must be in zypper (AFAIK not yet available).
"handle" by asking the user. But then there is no way to make my above use-cases work with that requirement encoded in the package.
An automatic handling must be introduced in frontends because rpm is the wrong place for it. (e. g. zypper: "Following debuginfo packages will be removed because of not matching versions:")
So, no, I think adding a requires is a step in the completely wrong direction. Btw, see the initial description on how existing tools can link %name and %name-debuginfo (if not simply looking at the package name only). I think this -debuginfo stuff is purely a frontend issue, apart from maybe providing a more reliable link from %name-debuginfo to %name (you can add a Provides: debuginfo(pkg) = %name or similar).
With 'Requires: %name = %version-%release' rpm provides the *right* link between %name-debuginfo and %name for joe user (and I assume in 99.99 % of cases). A 'Provides: debuginfo(pkg) = %name' cannot do it since it does not provide the neccessary link (packages should have same %version-%release) between the packages. Altogether: rpm must provide the neccessary link (depend on %name = %version-%release) for 99.99 % of cases - frontends must be able to handle exceptions. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=658212 https://bugzilla.novell.com/show_bug.cgi?id=658212#c8 --- Comment #8 from Richard Guenther <rguenther@suse.com> 2011-08-29 08:13:37 UTC --- Btw, I talked with mls and we had your change at some point but it was reverted as it causes updates to no longer be considered if you for example install glibc and glibc-debuginfo and then remove the debuginfo channel. That's clearly not acceptable as it is a security issue. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=658212 https://bugzilla.novell.com/show_bug.cgi?id=658212#c9 Michael Andres <ma@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |mls@suse.com --- Comment #9 from Michael Andres <ma@suse.com> 2012-10-29 14:23:13 CET --- @Michael: Will there be another attempt/approach? Or WONTFIX? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com