[opensuse-factory] some update funnies with debug packages
Hi, I'm observing some funnies with TW upgrades of debug packages right now. Let's examine this for the core of Qt5. $ zyp dup | grep -E 'libqt5-qtbase|libQt5Core5' libQt5Core5-debuginfo libqt5-qtbase-debugsource Hrmpf, zypper suppresses the verbose listing, when redirected. C&P: libQt5Core5-debuginfo 5.14.0-1.1 -> 5.14.1-1.1 libqt5-qtbase-debugsource 5.14.0-1.1 -> 5.14.1-1.1 $ rpmg 'libqt5-qtbase|libQt5Core5' libQt5Core5-5.14.0-1.1.x86_64 libQt5Core5-debuginfo-5.14.0-1.1.x86_64 libqt5-qtbase-common-devel-5.14.0-1.1.x86_64 libqt5-qtbase-debugsource-5.14.0-1.1.x86_64 libqt5-qtbase-devel-5.14.0-1.1.x86_64 libqt5-qtbase-examples-5.14.0-1.1.x86_64 libqt5-qtbase-platformtheme-gtk3-5.14.0-1.1.x86_64 Obviously, debug is "in front" of oss repos. Indeed: Index of download.opensuse.org/tumbleweed/repo/ [DIR] debug/ 04-Feb-2020 08:08 - [DIR] oss/ 29-Jan-2020 18:33 - which is somewhat unfortunate, but syncing out repos is constrained from too many factors already. Adhering to dependencies would be an additional nightmare on its own, I'm sure. Installing the upgrade would destroy the proper debugability of Qt5. Which reveals the question, why are the debug packages disjoint from the main packages? $ for opt in requires recommends suggests supplements enhances; do echo $opt:; rpm -q --$opt libQt5Core5-debuginfo; done requires: rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1 recommends: libqt5-qtbase-debugsource(x86-64) = 5.14.0-1.1 suggests: supplements: enhances: $ for opt in requires recommends suggests supplements enhances; do echo $opt:; rpm -q --$opt libqt5-qtbase-debugsource; done requires: rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1 recommends: suggests: supplements: enhances: In all my naivety, I would think, that the debug packages should depend on the base packages in question, but a more relaxed dependency is fine as well. No dependency at all isn't the real McCoy at least. I'm sure, there are reasons for the disjointedness of these, probably to avoid too much churn, but the consequences aren't that nice either: if you fiddle with debug packages, more often than not, they disperse, and are hard to keep in sync without machines help. Cheers, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2020-02-04 at 11:09 +0100, Hans-Peter Jansen wrote:
Hi,
I'm observing some funnies with TW upgrades of debug packages right now.
Let's examine this for the core of Qt5.
Just a timing issue - the debug repo is out before the snapshot (seems we don't have the 2-hour hold on the src and debug repos) Cheers, Dominique
Am Dienstag, 4. Februar 2020, 11:12:23 CET schrieb Dominique Leuenberger / DimStar:
On Tue, 2020-02-04 at 11:09 +0100, Hans-Peter Jansen wrote:
Hi,
I'm observing some funnies with TW upgrades of debug packages right now.
Let's examine this for the core of Qt5.
Just a timing issue - the debug repo is out before the snapshot (seems we don't have the 2-hour hold on the src and debug repos)
Sure, no problem with that. But the general debug vs. base package dependency issue needs still to be discussed, as tighter dependency would greatly improve the debugability on openSUSE machines, as well as the general fitness as a development workstation, wouldn't it? BTW, the 2 hour hold for those repos wouldn't be an issue than. zypper would note, that the dependent base packages aren't ready, and therefor wouldn't suggest updating the debug packages. Also, the case of swapping repos, where the old provides debug packages, while the new don't, could be handled more gracefully: zypper would note, that the new packages doesn't have accompanying debug packages, and suggest deinstalling them. The user has the choice: switching repos and loosing debug facility, or keep the state. IN any case: no more dangling debug packages. I hope, you get my point. Cheers, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2020-02-04 11:48, Hans-Peter Jansen wrote:
BTW, the 2 hour hold for those repos wouldn't be an issue than. zypper would note, that the dependent base packages aren't ready, and therefor wouldn't suggest updating the debug packages.
zypper looks at dependencies, just as it should. There is, however, no dependency between foo and foo-debuginfo (let alone foo-debugsource). This causes debuginfo/debugsource package to stick around, or to mismatch with the installed binaries, or or. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Dienstag, 4. Februar 2020, 13:23:15 CET schrieb Jan Engelhardt:
On Tuesday 2020-02-04 11:48, Hans-Peter Jansen wrote:
BTW, the 2 hour hold for those repos wouldn't be an issue than. zypper would note, that the dependent base packages aren't ready, and therefor wouldn't suggest updating the debug packages.
zypper looks at dependencies, just as it should.
There is, however, no dependency between foo and foo-debuginfo (let alone foo-debugsource). This causes debuginfo/debugsource package to stick around, or to mismatch with the installed binaries, or or.
That's, what I tried to express, Jan, but failed, obviously.. Let's try again: Can we *please* add a dependency between debuginfo and the base packages? Thanks, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 4 Feb 2020, Hans-Peter Jansen wrote:
Am Dienstag, 4. Februar 2020, 13:23:15 CET schrieb Jan Engelhardt:
On Tuesday 2020-02-04 11:48, Hans-Peter Jansen wrote:
BTW, the 2 hour hold for those repos wouldn't be an issue than. zypper would note, that the dependent base packages aren't ready, and therefor wouldn't suggest updating the debug packages.
zypper looks at dependencies, just as it should.
There is, however, no dependency between foo and foo-debuginfo (let alone foo-debugsource). This causes debuginfo/debugsource package to stick around, or to mismatch with the installed binaries, or or.
That's, what I tried to express, Jan, but failed, obviously..
Let's try again:
Can we *please* add a dependency between debuginfo and the base packages?
We've discussed that back when -debuginfo packages were split and we started to use build-ids. There wasn't a clear conclusion apart from that classical rpm dependencies are not going to do what you want. The most "obvious" choice (and leanest on non-debug packages) would be to add something like Supplements: glibc = <version> from say glibc-debuginfo. But that will get you debuginfo installed by default (oops). So back when discussing things I wanted to put the build-ids in the main package meta. So complementing the -debuginfo Provides which looks like debuginfo(build-id) = 7888b2558f69e6d2eb8326eb0699d02a2367444d the main package would have a Provides build-id = 7888b2558f69e6d2eb8326eb0699d02a2367444d and we can implement "magic" modes in the RPM solver. Two obvious modes exist: - remove no longer up-to-date -debuginfo packages - update -debuginfo packages together with main packages depending on your usecase both can be appropriate. There was push back against this because packages like coreutils with tons of binaries will get a _lot_ of additional package meta via those Provides. Since it's only interesting for _installed_ packages (where we have the actual binaries) in theory the RPM meta doesn't have to record the build-ids but instead they can be collected during RPM install (into a separate db?). Anyway, the conclusion is that a simple "dependency" doesn't work. Micha - do I remember correctly? Thanks, Richard. -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
On Wed, Feb 05, 2020 at 09:32:53AM +0100, Richard Biener wrote:
We've discussed that back when -debuginfo packages were split and we started to use build-ids. There wasn't a clear conclusion apart from that classical rpm dependencies are not going to do what you want.
The most "obvious" choice (and leanest on non-debug packages) would be to add something like Supplements: glibc = <version> from say glibc-debuginfo. But that will get you debuginfo installed by default (oops).
So back when discussing things I wanted to put the build-ids in the main package meta. So complementing the -debuginfo Provides which looks like
debuginfo(build-id) = 7888b2558f69e6d2eb8326eb0699d02a2367444d
the main package would have a Provides
build-id = 7888b2558f69e6d2eb8326eb0699d02a2367444d
and we can implement "magic" modes in the RPM solver. Two obvious modes exist:
- remove no longer up-to-date -debuginfo packages - update -debuginfo packages together with main packages
depending on your usecase both can be appropriate. There was push back against this because packages like coreutils with tons of binaries will get a _lot_ of additional package meta via those Provides.
Since it's only interesting for _installed_ packages (where we have the actual binaries) in theory the RPM meta doesn't have to record the build-ids but instead they can be collected during RPM install (into a separate db?).
Anyway, the conclusion is that a simple "dependency" doesn't work.
Micha - do I remember correctly?
I'm not sure if we really need all the new provides, a simple Requires: main-package in the debuginfo should be good enough for us. We definitly need a new job type in the solver to tell it that it can remove debuginfo packages if they get in the way. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 2020-02-05 11:59, Michael Schroeder wrote:
I'm not sure if we really need all the new provides, a simple
Requires: main-package
in the debuginfo should be good enough for us.
Requires: main-package = %version-%release -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 2020-02-05 12:15, Jan Engelhardt wrote:
On Wednesday 2020-02-05 11:59, Michael Schroeder wrote:
I'm not sure if we really need all the new provides, a simple
Requires: main-package
in the debuginfo should be good enough for us.
Requires: main-package = %version-%release
Actually... neither of the two will reliably work, because some packages do not produce a main-package. Think our shared libraries: Name: libHX %package -n libHX28 %package -n libHX28-devel Requires: libHX28=%version [implicit]%package -n libHX28-debuginfo Requires: libHX That won't fly. "libHX" is only a resolvable as a srpm, but there is no brpm with this symbol. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 5 Feb 2020, Jan Engelhardt wrote:
On Wednesday 2020-02-05 12:15, Jan Engelhardt wrote:
On Wednesday 2020-02-05 11:59, Michael Schroeder wrote:
I'm not sure if we really need all the new provides, a simple
Requires: main-package
in the debuginfo should be good enough for us.
Requires: main-package = %version-%release
Actually... neither of the two will reliably work, because some packages do not produce a main-package. Think our shared libraries:
Name: libHX %package -n libHX28 %package -n libHX28-devel Requires: libHX28=%version [implicit]%package -n libHX28-debuginfo Requires: libHX
That won't fly. "libHX" is only a resolvable as a srpm, but there is no brpm with this symbol.
It's surely possible to add such Requires, the implementation details are of course more elaborate (there's also DWZ eventually creating a "main" debuginfo package containing common parts of libfoobar1-debuginfo and libfoobaz2-debuginfo if it doesn't exist because of binary tools). That said, rpm, when creating -debuginfo packages, knows to which packages the corresponding binaries go. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 5 Feb 2020, Jan Engelhardt wrote:
On Wednesday 2020-02-05 11:59, Michael Schroeder wrote:
I'm not sure if we really need all the new provides, a simple
Requires: main-package
in the debuginfo should be good enough for us.
Requires: main-package = %version-%release
Well, reality is that it's main-package with the build-id the debuginfo is for. Now the question is what happens when you have main-package and main-package-debuginfo installed and try to update with the debuginfo repo disabled (for example). Or what happens if you deinstall main-package. So I think a "Requires" in the RPM sense is wrong. And since we need solver support anyways for anything else (and to not mess with other tools using the RPM info) using the build-id that is already there is a) more correct, b) not so much more difficult (as said, you don't actually need the Provides, just look at the installed binaries). Richard. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Feb 05 2020, Richard Biener wrote:
On Wed, 5 Feb 2020, Jan Engelhardt wrote:
Requires: main-package = %version-%release
Well, reality is that it's main-package with the build-id the debuginfo is for. Now the question is what happens when you have main-package and main-package-debuginfo installed and try to update with the debuginfo repo disabled (for example).
Or what happens if you deinstall main-package.
In both cases you get a conflict, which you should be able to resolve by removing the offending debuginfo package. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (6)
-
Andreas Schwab -
Dominique Leuenberger / DimStar -
Hans-Peter Jansen -
Jan Engelhardt -
Michael Schroeder -
Richard Biener