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

[Geoff Simmons]

On 8/24/21 18:36, Dridi Boukelmoune wrote:
> 
> They should ideally provide a version, but since we have packaging
> that could compete with first party packages we can't really predict
> what version we would go against.

Got it.

> I think the reason why we didn't want the traditional separation
> debuginfo package was the poor quality of panic backtraces. Once
> split, installing the separate debuginfo wouldn't improve the
> backtraces.

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.

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?


Best,
Geoff
-- 
** * * UPLEX - Nils Goroll Systemoptimierung

Scheffelstraße 32
22301 Hamburg

Tel +49 40 2880 5731
Mob +49 176 636 90917
Fax +49 40 42949753

http://uplex.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20210824/2012bada/attachment.bin>