Talk:Makepkg

From ArchWiki
Latest comment: 3 March by Arash in topic Package output more options

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)Reply[reply]

Indeed, but also note that upx will not be included in pacman in the future, which is why I am providing it with makepkg-optimizeAUR. 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)Reply[reply]

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)Reply[reply]

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)Reply[reply]

/* 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 trilinosAUR 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)Reply[reply]
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)Reply[reply]
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)Reply[reply]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]