Mailing List Archive

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

The spec file for RPM packages:

https://raw.githubusercontent.com/varnishcache/pkg-varnish-cache/master/redhat/varnish.spec

... has this passage:

Provides: varnish-libs%{?_isa} = %{version}-%{release}
Provides: varnish-libs = %{version}-%{release}
Obsoletes: varnish-libs

Provides: varnish-docs = %{version}-%{release}
Obsoletes: varnish-docs

Provides: varnish-debuginfo%{?_isa} = %{version}-%{release}
Provides: varnish-debuginfo = %{version}-%{release}
Obsoletes: varnish-debuginfo

This may be an RPM technique that I'm not familiar with, but why does it
have both Provides and Obsoletes for -libs, -docs and -debuginfo?

Since the Obsoletes don't specify a version, my best guess is that it's
something about updating to newer versions. But wouldn't newer versions
(newer version and RPM release number) be enough for that?

Asking because I'm building a custom RPM package for which I'd also like
to have the debuginfo. Creating the debuginfo RPM is easy enough, by
removing this line from the spec:

%global debug_package %{nil}

But then when you try to run debuginfo-install, it says that the
debuginfo package is obsoleted by the Varnish package.

I can get the debuginfo to install by removing the Obsoletes line for
varnish-debuginfo, and rebuilding the RPMs. But I'm confused about why
it was there in the first place, and concerned that I may have broken
something else by doing so.


Thanks,
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
Re: Packaging: why does the RPM spec have both Provides & Obsoletes for the same packages? [ In reply to ]
Hey Geoff,

On Tue, Aug 24, 2021 at 2:40 PM Geoff Simmons <geoff@uplex.de> wrote:
>
> Hello,
>
> The spec file for RPM packages:
>
> https://raw.githubusercontent.com/varnishcache/pkg-varnish-cache/master/redhat/varnish.spec
>
> ... has this passage:
>
> Provides: varnish-libs%{?_isa} = %{version}-%{release}
> Provides: varnish-libs = %{version}-%{release}
> Obsoletes: varnish-libs
>
> Provides: varnish-docs = %{version}-%{release}
> Obsoletes: varnish-docs
>
> Provides: varnish-debuginfo%{?_isa} = %{version}-%{release}
> Provides: varnish-debuginfo = %{version}-%{release}
> Obsoletes: varnish-debuginfo
>
> This may be an RPM technique that I'm not familiar with, but why does it
> have both Provides and Obsoletes for -libs, -docs and -debuginfo?
>
> Since the Obsoletes don't specify a version, my best guess is that it's
> something about updating to newer versions. But wouldn't newer versions
> (newer version and RPM release number) be enough for that?

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.

Keeping Provides doesn't break an installation of -docs for example,
because ultimately the package containing the docs is going to be
installed thanks to the Provides.

> Asking because I'm building a custom RPM package for which I'd also like
> to have the debuginfo. Creating the debuginfo RPM is easy enough, by
> removing this line from the spec:
>
> %global debug_package %{nil}
>
> But then when you try to run debuginfo-install, it says that the
> debuginfo package is obsoleted by the Varnish package.
>
> I can get the debuginfo to install by removing the Obsoletes line for
> varnish-debuginfo, and rebuilding the RPMs. But I'm confused about why
> it was there in the first place, and concerned that I may have broken
> something else by doing so.

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.

I think this specific point was a result of:

https://github.com/varnishcache/varnish-cache/commit/95437e6c882f2c2b332be94060a7ac96907db322

It's been a while, I don't remember the details.

Cheers,
Dridi
_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
Re: Packaging: why does the RPM spec have both Provides & Obsoletes for the same packages? [ In reply to ]
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
Re: Packaging: why does the RPM spec have both Provides & Obsoletes for the same packages? [ In reply to ]
> 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
_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev