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