Packaging: why does the RPM spec have both Provides & Obsoletes for the same packages?

[Dridi Boukelmoune]

> OK ... hmmm. My experience has been that the information available in a
> panic's stack trace, or to gdb for a coredump, has been relatively
> barren. The binary isn't stripped, so you can see function names, but
> that's about it, everything else is mostly question marks and hex digits.
>
> Assertions are an exception, of course, because the names and source
> code line are in the string. But otherwise we have sometimes resorted to
> deciphering addresses and offsets and disassembled code. That can get
> you surprisingly far, but it could be so much easier.
>
> With the debuginfo installed, I could see everything in gdb, just the
> way you like it.

What I meant is, once the debuginfo was split in its own package we
would lose symbol names in the backtrace whether or not the mathing
debuginfo package was installed.

At the time we didn't have libunwind support and I suspect it might solve
this problem if it still exists. The quality of libunwind backtraces is clearly
higher.

I experimented with libdwarf to add the source file, source line (sometimes
off by one) and binary file. Including VMODs! But well, that's an extra
dependency and a fair amount of additional panic code...

> Dridi thanks for the info, I won't worry about the debuginfo disrupting
> something else. Since it seems to work well, maybe the Varnish project
> can consider putting debuginfo RPMs on packagecloud as well? Like I
> said, I couldn't get it to install without removing the Obsoletes line,
> so that would have to be cleared up.
>
> PR or issue for pkg-varnish-cache?

PR is probably better, once we agree on an outcome the change is just
a few clicks away from being merged :)

I would love to default to libunwind but last time we brought this up the
idea was shot down, but, something tells me that it would stand a better
chance today.

Cheers