Talk:Makepkg

upx

A feature to be aware of: do not be surprised if the UPX option does not compress your gcc binary because it only detects files that are of mime type 'application/x-executable' | 'application/x-dosexec' while gcc unless instructed otherwise would create by default a binary 'application/x-sharedlib'. This is visible in /usr/share/makepkg/tidy/upx.sh Kewl (talk) 15:33, 1 January 2018 (UTC)

Indeed, but also note that upx will not be included in pacman in the future, which is why I am providing it with makepkg-optimize^AUR. I am willing to add other mimetypes to this list, provided we can establish that it is in fact safe to compress them with upx. I've found very little about the matter by searching, so we'll probably have to conduct our own tests.

Note, you could do such tests for yourself by appending | 'application/x-sharedlib', etc to the list in /usr/share/makepkg/tidy/upx.sh, before the ) at the end of the line. This seems relevant. quequotion (talk) 12:25, 16 February 2019 (UTC)

CARCH and CHOST

Can we get some information detailing about how to use these variables properly in makepkg.conf?

My CPU supports x86_64_v3, but I want to make sure that I do this right in makepkg.conf, and it would be useful information to have for those such as myself with no prior experience of dabbling with specific architectures.

Neko-san (talk) 21:39, 9 December 2021 (UTC)

Building from files in memory

Am I correct in my understanding that this tip: https://wiki.archlinux.org/title/Makepkg#Building_from_files_in_memory will result in filling up the RAM over time, assuming no reboot, to the point of rendering the system unusable? (And if so, that a strong warning should be warranted?)

(If I'm following correctly, the proposal to set `BUILDDIR=/tmp/makepkg` in makepkg.conf is the dangerous part, I used that setting for years following this tip before I understood the implications, and in these years likely had my system crash for lack of memory a few times.)

—This unsigned comment is by Bonob (talk) 22:13, 9 January 2023. Please sign your posts with ~~~~!

tmpfs does not grow infinitely; it has a fixed upper bound. According to Tmpfs#Examples, the default value for this upper bound is half of your total memory. From personal experience (of compiling Linux kernels past a certain versions, and web browsers), you will probably run out of space in /tmp before your system becomes unusable. In the scenario in which you do exhaust half of your memory this way and use up the rest of it, the Linux kernel should start evacuating pages to swap (which I recommend you have setup), and then invoke oom-killer to start killing processes to free memory. Both of those mechanisms try to be smart about the sacrifices that they make.

I don't really think a strong warning is necessary:

• There is already a note cautioning you against running out of memory.
• If you are someone who leaves their computer on, then I don't think it's that unreasonable to be more sensitive about filling up /tmp without explicitly being told.

-- CodingKoopa (talk) 22:54, 10 January 2023 (UTC)

/* Parallel compilation */ Directly using nproc to determine the number of jobs you can run is not good practice and RAM needs to be considered.

I do not have a source, but it's my understanding that gcc can use upwards of 1.5-2GB of ram per job during compilation, and as such it is recommended to limit the number of jobs to how many GB of RAM a system has divided by 2 or the output of `nproc`, whichever is the lower value. Apologies if I'm not following procedure to edit the wiki, this is my first edit.

—This unsigned comment is by Parax (talk) 2023-01-30T19:07:33. Please sign your posts with ~~~~!

Those limits are arbitrary, e.g. packages like trilinos^AUR exceed them by a large margin. There are also other compilers than gcc, tests can be run, etc. -- Alad (talk) 19:15, 30 January 2023 (UTC)

I would think that basing the job recommendations on a safer lower limit would be more beneficial to newer users on the wiki. More advanced users are better aware of the edge cases.

—This unsigned comment is by Parax (talk) 2023-01-30T19:24:32. Please sign your posts with ~~~~!

Except there's nothing pointing out those are safe lower limits or a general case. A new user seeing an arbitrary limit would only end up disappointed when it's exceeded or not met. -- Alad (talk) 21:13, 30 January 2023 (UTC)

The numbers can't be included in a general note. I'd be fine with at most something very general like "Avoid compiling larger packages in tmpfs to prevent running out of memory." in Makepkg#Building from files in memory. — Lahwaacz (talk) 22:48, 30 January 2023 (UTC)

Package output more options

I don't know whether it is a good idea, but I always wanted to have options for different folders in the $startdir, so it is not completely messed with lots of files.

I achieved this with the following options in makepkg.conf:

PKGDEST="$startdir/build/packages/"

SRCDEST="$startdir/build/sources/"

SRCPKGDEST="$startdir/build/srcpackages/"

LOGDEST="$startdir/logs/"

I would like to add this to the wiki article, but I wanted to ask first in case there are downsides or this is considered bad practice etc. G3ro (talk) 17:32, 29 February 2024 (UTC)

This may work when you build packages directly with makepkg, but it will randomly break with other build tools like AUR helpers that may source makepkg.conf in a context where $startdir is not defined. — Lahwaacz (talk) 22:16, 2 March 2024 (UTC)

Ok, thx for the info, I didn't think about AUR helpers, so maybe I could add it to the Tips & Tricks Section and add a note to it, about potential effects on AUR helpers etc.

G3ro (talk) 12:16, 3 March 2024 (UTC)

Although, $startdir is declared simply as the current working dir [1]. So it is not a big deal to set the value if undefined.

Hanabishi (talk) 12:34, 3 March 2024 (UTC)

All the PKGDEST etc. variables are expected to be absolute paths and you can't know in which context each helper sources the config file. — Lahwaacz (talk) 13:22, 3 March 2024 (UTC)

Well, I think big warning at the top of AUR helpers speaks for itself. If some random helper has weird behavior, it is not our responsibility to account for that.

Hanabishi (talk) 13:31, 3 March 2024 (UTC)

I added a section to Tips & Tricks and also added a Note, just in case.

But @Hanabishi you are of course right, that the users need to expect differences and if an AUR helper uses the makepkg.conf file, they should also use $startdir correctly.

G3ro (talk) 15:07, 3 March 2024 (UTC)

Well, the whole AUR is unsupported officially. Just like AUR helpers.

AUR Helpers may have strange behaviours, just like AUR PKGBUILDs...

Arash (talk) 23:53, 3 March 2024 (UTC)

Removing slow compressor

How about removing show traditional compressors.

lz4 and zstd for speed, zstd --long -9~19 for size is enough

Makepkg#Utilizing multiple cores on compression oech3 (talk) 04:34, 12 April 2025 (UTC)

Why not just keep listing all? Users can choose themselves if they want something non-default for whatever reason. — Lahwaacz (talk) 15:27, 12 April 2025 (UTC)

About exporting values unsuppoted by makepkg

BUILDDIR does not cover about caches for Go,Rust,npm,pnpm,yarn,... We can export to change path of them at makepkg.conf. But is it clean and fine to add to wiki? oech3 (talk) 13:23, 26 May 2025 (UTC)

Does it work if you use that makepkg.conf for DeveloperWiki:Building in a clean chroot? — Lahwaacz (talk) 08:47, 1 June 2025 (UTC)

It does not use every seting at /etc/makepkg.conf in my understanding since devtools have /usr/share/devtools/makepkg.conf.d oech3 (talk) 09:41, 1 June 2025 (UTC)

You did not say what you are exporting and where so it is hard to discuss. The mkarchroot command has an -M flag. — Lahwaacz (talk) 09:51, 1 June 2025 (UTC)

I have export CARGO_HOME=/tmp/cargo GOPATH=/tmp/gopath GOCACHE=/tmp/gocach at /etc/makepkg.conf for daily build (export is needed). Clean build with this setting puts cargo cache to unknown place... oech3 (talk) 10:26, 1 June 2025 (UTC)

panic=abort at RUSTFLAGS for binary size

@Lahwaacz This reduces binary size. (Is this improve performance for abort? I don't know).

What is the suitable section only for this? oech3 (talk) 18:28, 1 June 2025 (UTC)

1. Better performance and smaller binary size are often mutually exclusive
2. panic=abort will break applications that rely on panic handling (I don't know if there are any such apps in the official repositories, but this shouldn't be used mindlessly anyway)

— andreymal (talk) 19:12, 1 June 2025 (UTC)