[SOLVED] Why new "*-debug" packages are coming since couple of days?

papavlos · 2024-02-20 22:35:05

Please help me to understand why - when running daily yay - a new package "yay-bin-debug" wants to be installed together with regular "yay-bin" update?
I have noticed it recently, not only with "yay-bin" package but also with other AUR packages.

Is it necessary to install the "*-debug" packages?
If not - how to get rid of them when running yay? I mean - not to be downloaded, prepared and proposed to be added?

Last edited by papavlos (2024-02-20 23:33:22)

papavlos · 2024-02-20 22:52:43

A live example of the above:

Package (2)                   Old Version       New Version       Net Change

gmrender-resurrect-git        1:r345.3a1234f-1  1:r345.3a1234f-1   -0.01 MiB
gmrender-resurrect-git-debug                    1:r345.3a1234f-1    0.43 MiB

Total Installed Size:  0.55 MiB
Net Upgrade Size:      0.43 MiB

:: Proceed with installation? [Y/n]

Here even version number remains the same, simply the same package got rebuilt and split (?) into two, then proposed to be reinstalled/installed.
Is it the new default behavior for AUR?

loqs · 2024-02-20 22:55:06

Please see makepkg.conf.5#OPTIONS and [SOLVED] Cannot disable debug symbol packages with makepkg.conf also https://bbs.archlinux.org/viewtopic.php … 0#p2150180.
Please do not bump a thread. If you post is the last in a thread edit that existing post instead of creating a new one.

papavlos · 2024-02-20 23:38:47

Thanks @loqs ! As usual - pointing to the solution.

Modifying the "makepkg.conf" by adding exclamation mark before "debug" in "OPTIONS" line and cleaning the ~/.cache/yay contents fixes my issue.

Next time I will not bump threads and will follow recommended rules.

abcd567 · 2025-02-09 21:26:14

For building packages using PKGBUILD from AUR (or created myself), I use following command which prevents makepkg to create and install debug package.

No need to modify any config file:

makepkg -si OPTIONS=-debug

The minus (-) sign at start of "debug" means "do NOT create and install debug package

EDIT:
Above solution does not build a debug package, but includes the debug symbol in the main package itself..

Another solution, which does NOT build debug package, as well as does NOT includes the debug symbol in the main package itself is given below:

Edit file PKGBUILD and add following line:

options=('!debug')

Then issue command:

makepkg -si

.

Last edited by abcd567 (2025-02-10 04:28:45)

loqs · 2025-02-09 22:03:04

abcd567 wrote:

For building packages using PKGBUILD from AUR (or created myself), I use following command which prevents makepkg to create and install debug package.
No need to modify any config file:
makepkg -si OPTIONS=-debug 
The minus (-) sign at start of "debug" means "do NOT create and install debug package

Unlike changing the /etc/makepkg.conf or the OPTIONS array in the PKGBUILD your solution includes the debug symbol in the package itself.

abcd567 · 2025-02-10 04:26:12

loqs wrote:

Unlike changing the /etc/makepkg.conf or the OPTIONS array in the PKGBUILD your solution includes the debug symbol in the package itself.

You are right.
I have edited my post and added method to include options=('!debug') in PKGBUILD.
Building package this way, I saw following output:

Stripping unneeded symbols from binaries and libraries...

However I do not see any harm if the main package includes debug symbols, as long as it does not build a separate debug package. The difference in size of package with and without debug symbols is less than 3 Mb. I feel using command "makepkg -si OPTIONS=-debug" is better and easier than modifying the file PKGBUILD and adding "options=('!debug')".

Last edited by abcd567 (2025-02-10 04:42:37)

loqs · 2025-02-10 12:16:38

abcd567 wrote:

The difference in size of package with and without debug symbols is less than 3 Mb.

The size of the debug symbols is package dependent.

abcd567 wrote:

I feel using command "makepkg -si OPTIONS=-debug" is better and easier than modifying the file PKGBUILD and adding "options=('!debug')".

That still leaves changing /etc/makepkg.conf if you do not want to build debug packages or include debug symbols by default. The following prevents debug symbols being added on the command line:

OPTIONS=(\!debug) makepkg

abcd567 · 2025-02-10 20:27:42

loqs wrote:

That still leaves changing /etc/makepkg.conf if you do not want to build debug packages or include debug symbols by default. The following prevents debug symbols being added on the command line:
OPTIONS=(\!debug) makepkg

The PKGBUILD files I created are for use by a group of my friends. I cannot edit everyone's file /etc/makepkg.conf.
Some of these friends are not proficient enough to do it safely, even if I tell them how to do it.
A simpler thing is to tell them to use the command makepkg -si OPTIONS=-debug, OR makepkg -si OPTIONS='!debug'.
This also has advantage that debug symbols are included inside the main package, so we don't loose facility to debug any runtime errors.

Now the reason why I want to avoid creation of separate debug packages is that the package I want to build requires some dependencies which are not available from Arch repo. These required to be built from AUR. After building & installing the dependencies (packages+debug packages), I ran makepackage -si on the PKGBUID which waswritten by me as the main app. This created the package and debug packages OK, and tried to install these but failed due to conflict between debug package of one of dependecies, and the main package of the app. I tried to install main app's package alone without installing it's associated debug package, but that also failed. Only when I removed the debug package of dependency, I succeeded in installing the main app. That made me to find out a way to stop building a separate debug package.

loqs · 2025-02-10 21:15:23

abcd567 wrote:

This also has advantage that debug symbols are included inside the main package, so we don't loose facility to debug any runtime errors.

Getting_traces#Compilation_options

options=(debug !strip)

This has the advantage of being documented / supported.

abcd567 · 2025-02-11 01:03:42

loqs wrote:

Getting_traces#Compilation_options
options=(debug !strip)
This has the advantage of being documented / supported.

Thank you. This is great.

loqs · 2025-02-11 21:25:43

abcd567 wrote:

Now the reason why I want to avoid creation of separate debug packages is that the package I want to build requires some dependencies which are not available from Arch repo. These required to be built from AUR. After building & installing the dependencies (packages+debug packages), I ran makepackage -si on the PKGBUID which waswritten by me as the main app. This created the package and debug packages OK, and tried to install these but failed due to conflict between debug package of one of dependecies, and the main package of the app. I tried to install main app's package alone without installing it's associated debug package, but that also failed. Only when I removed the debug package of dependency, I succeeded in installing the main app. That made me to find out a way to stop building a separate debug package.

This should not be happening but without the PKGBUILD and reltad pacman output's it is not possible to understand the cause. Almost all binary packages in arch are split debug and I am not aware of a similar report to yours.

Scimmia · 2025-02-11 21:51:35

There are, in fact, issues with debug packages conflicting with each other. When packages bundle the same binaries, the symbols from those binaries end up conflicting even though the binaries themselves are installed to different places.

loqs · 2025-02-11 21:58:11

Scimmia wrote:

There are, in fact, issues with debug packages conflicting with each other. When packages bundle the same binaries, the symbols from those binaries end up conflicting even though the binaries themselves are installed to different places.

abcd567 switched from split debug packages to including debug symbols in the main package. Would that not move that issue to the main package as well?

Scimmia · 2025-02-11 22:19:25

No, because that leaves the symbols as part of the binaries instead of stripping them into detached symbols.

Arch Linux

#1 2024-02-20 22:35:05

[SOLVED] Why new "*-debug" packages are coming since couple of days?

#2 2024-02-20 22:52:43

Re: [SOLVED] Why new "*-debug" packages are coming since couple of days?

#3 2024-02-20 22:55:06

Re: [SOLVED] Why new "*-debug" packages are coming since couple of days?

#4 2024-02-20 23:38:47

Re: [SOLVED] Why new "*-debug" packages are coming since couple of days?

#5 2025-02-09 21:26:14

Re: [SOLVED] Why new "*-debug" packages are coming since couple of days?

#6 2025-02-09 22:03:04

Re: [SOLVED] Why new "*-debug" packages are coming since couple of days?

#7 2025-02-10 04:26:12

Re: [SOLVED] Why new "*-debug" packages are coming since couple of days?

#8 2025-02-10 12:16:38

Re: [SOLVED] Why new "*-debug" packages are coming since couple of days?

#9 2025-02-10 20:27:42

Re: [SOLVED] Why new "*-debug" packages are coming since couple of days?

#10 2025-02-10 21:15:23

Re: [SOLVED] Why new "*-debug" packages are coming since couple of days?

#11 2025-02-11 01:03:42

Re: [SOLVED] Why new "*-debug" packages are coming since couple of days?

#12 2025-02-11 21:25:43

Re: [SOLVED] Why new "*-debug" packages are coming since couple of days?

#13 2025-02-11 21:51:35

Re: [SOLVED] Why new "*-debug" packages are coming since couple of days?

#14 2025-02-11 21:58:11

Re: [SOLVED] Why new "*-debug" packages are coming since couple of days?

#15 2025-02-11 22:19:25

Re: [SOLVED] Why new "*-debug" packages are coming since couple of days?

Board footer