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