On Sun, 23 May 2021 20:15:30 +0100 Dave Howorth <dave@howorth.org.uk> wrote:

I was tempted to say +1 to this but then I thought that actually I, and I suspect most users, just want to use their systems without any pain and so debugging ought to be a fairly rare event. So then I have to consider whether it is worth investing the extra space and time to have debug information for everything versus the extra effort each time I need to debug anything. I'm not sure.

I wasn't for a moment proposing this be the *default* behavior. The way I imagine it, it should be a configurable flag in `zypper.conf`, perhaps `installDebug = yes` (similar to `installRecommends`) I'm personally very happy making the trade-off between increased disk space in exchange for having debuginfo always available when I need it (without having to first wait several minutes while `gdb` downloads debuginfo in a non-interruptible, non-parallelized manner, while also failing to successfully include source code information...)

But I use Leap. Perhaps the answer is different if you use TW? You don't say what you use?

I'm on tumbleweed, which is part of the issue. The problem is that manually installing debuginfo does not work very well because you have to re-install many debuginfo packages after system upgrades. As a case study, I very regularly debug applications that use `libavcodec`. At the moment, I have `libavcodec58_134` and `libavcodec58_134-debuginfo` installed. But when libavcodec gets automatically updated, for example to `libavcodec59_100`, the corresponding debuginfo package does not get installed alongside it. In this particular case, the problem can be avoided by installing the meta-package `ffmpeg-4-debuginfo`, although it requires manual action. (In particular, `gdb` doesn't tell me about this meta-package's existence, it instead prompts me to manually install `libavcodec*-debuginfo` and so on). But I've noticed issues similar to this cropping up all the time. I would prefer to avoid all this headache and manual action in favor of just being able to specify `installDebug = yes`, the way I can avoid this headache on gentoo by just enabling the `splitdebug` and `installsources` features in the portage configuration.

I think that for me the problem is that when it wants to update the files I have, it can take a couple minutes. So there I am on the trail of a mystery, and I suddenly have to wait and wait. And try to remember exactly what I was look for. I generally like the idea. But maybe a question first to see if you want it done? On Sun, May 23, 2021 at 11:45 PM J Leslie Turriff <jlturriff@mail.com> wrote:

On 2021-05-23 11:31:21 Niklas Haas wrote:

...

|Hello, | |I do a lot of debugging, and I generally find it annoying to have to |wait for debuginfo to become available. I'm used to distros such as |Gentoo where I can globally enable debuginfo for all packages, and never |have this problem ever again. | |I know that in recent times, openSuSE has started shipping gdb with the |annoying `libdebuginfod` which attempts solving this problem but fails |spectacularly. As such, I don't consider it a solution, for a number of |reasons that are besides the point. (To anybody finding this email via |google: comment out /etc/profile.d/debuginfod.sh to disable it) | |What I _want_ to have happen is for `zypper in <package>` to |automatically pull in `<package>-debuginfo` where available. Is there |any way at all to accomplish this? | |Thanks, |Niklas | |P.s.: It's possible with some parsing of the `zypper packages -i` output |to construct a command line that installs `<package>-debuginfo` for all |installed packages. However, this still has annoying shortcomings: | |1. Uninstalling packages doesn't auto-clean the (no longer needed) | debuginfo packages, thus causing them to continue littering the | system over time. | |2. This has to be re-run periodically in order to keep up with newly | installed packages.

There doesn't seem to be anything built into zypper to say 'include-debuginfo', but in theory one could place zypper-{in,rm}dbg commands somewhere in your path; in | /usr/lib/zypper/commands/ there is a command called | zypper-lifecycle for example. (The long name is irritating, but maybe tab-completion will help with that.)

info zypper explains this: | SUBCOMMANDS | Zypper subcommands are inspired by git(1). Subcommands are standalone executables | that live in the zypper_execdir (/usr/lib/zypper/commands). For subcommands | zypper provides a wrapper that knows where the subcommands live, and runs them by | passing command options and arguments to them. If a subcommand is not found in | the zypper_execdir, the wrapper will look in the rest of your $PATH for it. Thus, | it’s possible to write local zypper extensions that don’t live in system space. | | This is how to add your own subcommand zypper mytask: | | · The executable must be named zypper-mytask. | | · The executable must be located your $PATH. | | · A manpage for zypper-mytask should be provided and explaining the commands | options and return values. It will be shown when calling zypper help mytask. | | · Zypper built-in commands take precedence over subcommands with the same name. | | · It’s fine to call zypper or use libzypp from within your subcommand. | | You can use the built-in zypper subcommand command to get a list of all | subcommands in zypper_execdir and from elsewhere on your $PATH. | | Using zypper global-options together with subcommands, as well as executing | subcommands in zypper shell is currently not supported.

Leslie -- openSUSE Leap 15.2 x86_64

-- Roger Oberholtzer