Why does makepkg config now have debug enabled?

starfry · 2024-05-15 11:28:05

I have a build process that uses the arch iso to install a new system. I have just tried to use it after a few months of not using it. I had the usual expected task of bringing things up to date however there is one remaining issue I am unsure of that I'd appreciate some commentary on.

My build script runs on a clean Arch ISO live environment. It begins with a pacman -Syu to ensure it is bang up to date.

It then installs make gcc fakeroot into the live environment and proceeds to build AUR packages, however this now fails with an error

==> ERROR: Cannot find the debugedit binary required for including source files in debug packages.

I believe this has started to happen because debug has been enabled in /etc/makepkg.conf options. This happened in a change that was merged on Feb 6th. I can fix the problem by changing this value back to !debug like it was before the merge. Or I can install debugedit.

This is easily reproducible: netboot a live Arch env and then

$ mount -o remount,size=100% /run/archiso/cowspace
$ pacman -Syu
$ pacman -S make gcc fakeroot
$ cd /tmp
$ curl -s https://aur.archlinux.org/cgit/aur.git/snapshot/mkinitcpio-sd-zfs.tar.gz | tar zx 
$ chown -R nobody: mkinitcpio-sd-zfs
$ cd mkinitcpio-sd-zfs
$ sudo -u nobody makepkg

This will fail with the error. However, if you do this:

$ sed -i -e '/^OPTIONS=/s/debug/!debug/' /etc/makepkg.conf
$ sudo -u nobody makepkg

Then it works. Alternatively pacman -S debugedit.

My question is really about what this change brings to the party. Do I want debugedit or not? If so, why?

Or is this a change that slipped into that merge but isn't really required?

Allan · 2024-05-15 11:47:01

Arch devs decided that the makepkg.conf that they use to build system packages should be the same as the one they install on your system. This is the result.

Trilby · 2024-05-15 13:07:40

I was about to argue how stupid this change was not because I don't like the config setting, that's subjective and defaults are just defaults. But I was going to argue that it's stupid to have a default setting that will not work on a default system: either the debug option should not be enabled by default, or the necessary package debugedit should be a dependency of base-devel.

Of course before I posted such a rant I checked: debugedit is required by base-devel. If you are using makepkg and you do not have base-devel installed, you are doing it wrong. I may still subjectively dislike this being the default, but it is an internally consistent setup. You would not get this error if you were using makepkg properly (by installing base-devel).

EDIT: side-note, I do not have debugedit installed as I do not have base-devel installed. I've made my own slimmed down "aur-devel" package. But I'm aware of the fact that I'm using the AUR in an unsupported way. If / when stuff breaks as a result, that's on me. I diverged from using base-devel due to 'sudo' being included: PKGBUILDs should never use sudo, ever. So there's no reason for this to be in base-devel.

Last edited by Trilby (2024-05-15 13:14:42)

starfry · 2024-05-15 14:28:23

OK yes that makes sense. I was trying to install (into the live env) the barest minimum so as not to run out of space and that is why I had previously worked out what dependencies were required to build the packages I was using and I had it work successfully. The change to the debug setting broke that and led me to where we are. I could just install base-devel or change the makepkg config to remove debug. I guess that's my call and, as you say, on me if it breaks.

But seeing as we're here... what's the need for debug being enabled (other than convenience for the devs)? Am I losing something by disabling it (in makepkg config) that I don't know I need? I guess not given you've disabled it also.

I have noticed my images have bloated by around 20% since a few months ago. May be down to everything being built debug or may be just natural growth, I don't know.

Trilby · 2024-05-15 14:43:09

starfry wrote:

Am I losing something by disabling it (in makepkg config) that I don't know I need? I guess not given you've disabled it also.

My two cents on this may not be worth that much - but yes, I do not have debugging disabled, nor do I have base-devel installed. And this has been working very well for me. It'd be great if some of the devs using could present the case for the debug flag and what value it provides.

seth · 2024-05-15 14:59:40

"Backtraces" - the flag certainly makes sense for centrally mass-distributed packages because when users run into obscure issues signals, they can provide a backtrace that often makes it rather easy to debug the error and is typically requested upstream for that reason.

For local, private builds? Rather pointless default action.
Ifff you should indeed run into issues w/ a package you think a more detailed backtrace might be useful for you can enable it for that package you're building (and apparently debugging) yourself anyway - otherwise it's just bloat.

Just like with the default compression, context matters and some of the settings that are extremely reasonable in one context are not very smart in a another one.

Allan · 2024-05-16 00:47:43

Trilby wrote:

EDIT: side-note, I do not have debugedit installed as I do not have base-devel installed. I've made my own slimmed down "aur-devel" package. But I'm aware of the fact that I'm using the AUR in an unsupported way. If / when stuff breaks as a result, that's on me. I diverged from using base-devel due to 'sudo' being included: PKGBUILDs should never use sudo, ever. So there's no reason for this to be in base-devel.

More side note: As always, base-devel is packaged in the way the Arch Packagers need it to be. The Arch packaging buildsystem relies on sudo for setting up chroots etc. The fact that people decided this was a standard for the AUR is irrelevant in decision making at the packaging level. (I do not even have the "base" package installed - noone ever needs bzip2...)

abcd567 · 2025-02-09 21:20:45

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.

This is simple and easy.

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:14:28)

NuSkool · 2025-02-09 23:00:27

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.
This is simple and easy.

EDIT:
Nice! I've always relied on setting (prepending debug with !)ie: '!debug' in 'makepkg.conf' 'OPTIONS' array for this.

Did I overlook your solution 'OPTIONS=-debug' in the related man pages (makepkg, makepkg.conf, PKGBUILD) documentation?
Where did you find this?

Last edited by NuSkool (2025-02-10 02:35:07)

Allan · 2025-02-09 23:23:33

You did not overlook it because it is a really bad "solution".

NuSkool · 2025-02-10 00:25:23

Allan wrote:

You did not overlook it because it is a really bad "solution".

Although I didn't see the following skimming through the documentation, I did just verify that it works.ie: eliminated the debug package being built when the makepkg.conf is set to build it.

makepkg  OPTIONS='!debug' -sr

This makes more sense to me due to it being the method used in 'makepkg.conf'. Thoughts or opinion on using this?

The difference:
OPTIONS=-debug
OPTIONS='!debug'

Maybe abcd567 had a typo, but even then I found I had to single quote the option I used for it to work.

EDIT: Thinking out loud.... would this be added to or replace the 'OPTIONS' array in 'makepkg.conf'?

Last edited by NuSkool (2025-02-10 00:37:44)

Allan · 2025-02-10 00:44:10

NuSkool wrote:

EDIT: Thinking out loud.... would this be added to or replace the 'OPTIONS' array in 'makepkg.conf'?

Replaces - and as such the debug symbols are now included in the package and not stripped.

NuSkool · 2025-02-10 02:25:44

Allan wrote:

NuSkool wrote:
EDIT: Thinking out loud.... would this be added to or replace the 'OPTIONS' array in 'makepkg.conf'?
Replaces - and as such the debug symbols are now included in the package and not stripped.

Thanks for clearing this up Allan. I don't think anyone would want to use either of these then.

I'll add for anyone not understanding the details, stick to the documented methods if you just want to eliminate debug packages being built.
Change it it /etc/makepkg.conf, after reading man makepkg.conf , 'OPTIONS=' info on the array.

Unintentionally replacing the entire 'OPTIONS' array in '/etc/makepkg.conf' using an undocumented method with 'makepkg' is as Allan said:

a really bad "solution".

EDIT: YMMY depending on AUR helpers. They could use their own equivalent of 'makepkg.conf' and possibly a second for clean chroot building.

Last edited by NuSkool (2025-02-10 19:35:19)

abcd567 · 2025-02-10 04:11:22

NuSkool wrote:

EDIT:
Nice! I've always relied on setting (prepending debug with !)ie: '!debug' in 'makepkg.conf' 'OPTIONS' array for this.
Did I overlook your solution 'OPTIONS=-debug' in the related man pages (makepkg, makepkg.conf, PKGBUILD) documentation?
Where did you find this?

I found this solution only today by trial-and-error, and decided to post it in forum for benefit of the community.
The man pages do not give any idea about options to be used as flag with the makepkg command. I tried options=!debug, but it failed. Then I recalled that some place in man pages, it was mentioned that putting a minus (-) sign with flag results in stopping the option. So I tried options=-debug, and it worked.

I have edited my post and added info about adding options=('!debug') in PKGBUILD. The options=-debug does NOT work in the PKGBUILD. This one also I found by trial-and-error

abcd567 · 2025-02-10 06:54:58

NuSkool wrote:

Unintentionally replacing the entire 'OPTIONS' array in '/etc/makepkg.conf' using an undocumented method with 'makepkg' is as Allan said:
a really bad "solution".

Instead of using OPTIONS flag with makepkg command, add OPTIONS line in file PKGBUILD.
NOTE: Using += sign instead of = sign in PKBUILD wont replace the whole OPTIONS array, it will add !debug to the array.

OPTIONS=( !debug )  ## In PKGBUILD, do NOT use this one as it will replace whole OPTIONS array 

OPTIONS+=( !debug )  ## In PKGBUILD, use this one as it will not replace array, but will add !debug to array. Leave empty space on both sides of !debug

Allan · 2025-02-10 07:15:58

Why are you not editing the configuration file (/etc/makepkg.conf)? Surprisingly, the configuration file is for configuring your system.

abcd567 · 2025-02-10 19:50:19

Allan wrote:

Why are you not editing the configuration file (/etc/makepkg.conf)? Surprisingly, the configuration file is for configuring your system.

The reason is that 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) from AUR, I ran makepackage -si on the PKGBUID written by me, which 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.

Allan · 2025-02-10 21:10:48

OPTIONS=-debug is equivalent to OPTIONS="thisisdumb". It is pure gibberish.

If your friends really can not edit a configuration file, then (1) adding a line to a PKGBUILD is good - although all packages they build would need edited;;;, and (2) why are they using Arch?

loqs · 2025-02-10 21:25:53

Allan wrote:

OPTIONS=-debug is equivalent to OPTIONS="thisisdumb". It is pure gibberish.

Is it an issue that setting the environment variable OPTIONS has any effect on makepkg's behavior?

seth · 2025-02-10 23:10:50

Looks deliberate:

# attempt to consume any extra argv as environment variables. this supports
# overriding (e.g. CC=clang) as well as overriding (e.g. CFLAGS+=' -g').
extra_environment=()
while [[ $1 ]]; do
	if [[ $1 = [_[:alpha:]]*([[:alnum:]_])?(+)=* ]]; then
		extra_environment+=("$1")
	fi
	shift
done

abcd567 wrote:

I cannot edit everyone's file /etc/makepkg.conf. Some of these friends are not proficient enough to do it

Do your former friends know that you consider them too dense to use a text editor?
You could hand them a sed call to alter their config, though. Or pass the sed result to makepkg.

sed 's/\([^#]*\)OPTIONS=(\(.*[^!]\)debug/\1OPTIONS=(\2!debug/g' /etc/makepkg.conf | makepkg --config /dev/stdin

I'm not sure whether teaching them to type that kind of stuff into a terminal is a better idea than to simply reveal that there're other editors than vim…

NuSkool · 2025-02-11 00:52:32

Never mind....

Last edited by NuSkool (2025-02-11 01:33:19)

Allan · 2025-02-11 03:26:11

loqs wrote:

Allan wrote:
OPTIONS=-debug is equivalent to OPTIONS="thisisdumb". It is pure gibberish.
Is it an issue that setting the environment variable OPTIONS has any effect on makepkg's behavior?

There is two issues. (1) makepkg does not understand the "-" at the front - an ! is used to disable. and (2), setting OPTIONS in the environment overwrites all values in makepkg.conf (whether it should do that is another story). Fortunately the makepkg defaults are mostly sane.

seth · 2025-02-11 05:46:26

I think loqs meant more in a general sense, not just that this is a misleading way to shred the OPTIONS array.
But the code comment reasons it, any kind of filter ("but not this environment") is pointless because dumb stuff there will always screw you and plausibillity checks are impossible (even if you figure the compiler and keep a list of all or inquire all documented flags the user might still want to add an undocumented one) and if somebody wants to sudo read mail really fast you're not gonna stop them anyway.

A problem would be (didn't test) if makepkg would not replace any OPTIONS environment from the parenting shell.

abcd567 · 2025-02-11 07:57:17

Allan wrote:

(1) makepkg does not understand the "-" at the front - an ! is used to disable.

Although it is not documented, but makepkg does understand "-" at the front of an option. I have tested it. If you don't believe me, test it yourself.

Allan wrote:

(2), setting OPTIONS in the environment overwrites all values in makepkg.conf (whether it should do that is another story). Fortunately the makepkg defaults are mostly sane.

By placing OPTION after makepkg command, it acts as argument passed to the makepkg command, and does not change any environmental variable. It may affect environmental variable if it is placed BEFORE makepkg command or independently.
Even in this case it will need to be exported i.e "export OPTIONS=!debug"

Last edited by abcd567 (2025-02-11 08:17:30)

Allan · 2025-02-11 10:20:20

abcd567 wrote:

Allan wrote:
(1) makepkg does not understand the "-" at the front - an ! is used to disable.
Although it is not documented, but makepkg does understand "-" at the front of an option. I have tested it. If you don't believe me, test it yourself.

I was 99% sure I was right, given I have led makepkg development for more than a decade... but:

pkgname=options
pkgver=1
pkgrel=1
arch=('any')

package() {
	echo ${OPTIONS[@]}

	if check_option "debug" "y"; then
		echo "debug enabled"
	else
		echo "debug disabled"
	fi
}

> makepkg OPTIONS=-debug
....
==> Starting package()...
-debug docs !libtool !staticlibs emptydirs zipman purge debug lto
debug enabled

OK....

> makepkg OPTIONS=\!debug
....
==> Starting package()...
!debug docs !libtool !staticlibs emptydirs zipman purge debug lto
debug enabled

From the makepkg man page...

           This array contains options that affect default packaging. They are
           equivalent to options that can be placed in the PKGBUILD; the
           defaults are shown here. All options should always be left in the
           array; to enable or disable an option, simply remove or add an “!”
           at the front of the option. If an option is specified multiple
           times, the final value takes precedence.

So why is this "working"? Well... in the default makepkg.conf:

OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge debug lto)

Note "strip" at the start? Look at the makepkg run output.... it has been overwritten. I was wrong about the whole array being overwritten, but the first element is. So you have not disabled debug code at all. Just prevented it being stripped to a separate package.

This will not work in the next release of makepkg, because that is some screwy behaviour!

Arch Linux

#1 2024-05-15 11:28:05

Why does makepkg config now have debug enabled?

#2 2024-05-15 11:47:01

Re: Why does makepkg config now have debug enabled?

#3 2024-05-15 13:07:40

Re: Why does makepkg config now have debug enabled?

#4 2024-05-15 14:28:23

Re: Why does makepkg config now have debug enabled?

#5 2024-05-15 14:43:09

Re: Why does makepkg config now have debug enabled?

#6 2024-05-15 14:59:40

Re: Why does makepkg config now have debug enabled?

#7 2024-05-16 00:47:43

Re: Why does makepkg config now have debug enabled?

#8 2025-02-09 21:20:45

Re: Why does makepkg config now have debug enabled?

#9 2025-02-09 23:00:27

Re: Why does makepkg config now have debug enabled?

#10 2025-02-09 23:23:33

Re: Why does makepkg config now have debug enabled?

#11 2025-02-10 00:25:23

Re: Why does makepkg config now have debug enabled?

#12 2025-02-10 00:44:10

Re: Why does makepkg config now have debug enabled?

#13 2025-02-10 02:25:44

Re: Why does makepkg config now have debug enabled?

#14 2025-02-10 04:11:22

Re: Why does makepkg config now have debug enabled?

#15 2025-02-10 06:54:58

Re: Why does makepkg config now have debug enabled?

#16 2025-02-10 07:15:58

Re: Why does makepkg config now have debug enabled?

#17 2025-02-10 19:50:19

Re: Why does makepkg config now have debug enabled?

#18 2025-02-10 21:10:48

Re: Why does makepkg config now have debug enabled?

#19 2025-02-10 21:25:53

Re: Why does makepkg config now have debug enabled?

#20 2025-02-10 23:10:50

Re: Why does makepkg config now have debug enabled?

#21 2025-02-11 00:52:32

Re: Why does makepkg config now have debug enabled?

#22 2025-02-11 03:26:11

Re: Why does makepkg config now have debug enabled?

#23 2025-02-11 05:46:26

Re: Why does makepkg config now have debug enabled?

#24 2025-02-11 07:57:17

Re: Why does makepkg config now have debug enabled?

#25 2025-02-11 10:20:20

Re: Why does makepkg config now have debug enabled?

Board footer