BUILD(1)

hey bestie πŸ’– you've stumbled into build(1) from the General Commands Manual, and honestly? iconic. grab a boba, we're building packages 🫢

🌸 NAME 🌸

build β€” build SUSE Linux RPMs in a chroot environment ✨


πŸŽ€ SYNOPSIS πŸŽ€

build [--clean|--no-init] [--repo dir_or_url] [--repo...]  [--root
buildroot] [recipefile]
build --help
build --verify

πŸ’… DESCRIPTION πŸ’…

okay so build is THE tool for building binary packages in a safe and reproducible way. no chaos, no "it worked on my machine" energy. by default it builds inside a chroot sandbox, but bestie it can also build inside a virtual machine if you want extra security. main character energy fr fr πŸ”₯

if you hand it a recipe file on the command line, build will use that file and every other file in the directory to build the package. if you don't pass a recipe argument, it just goes looking through the current directory for a file. it finds one. it always finds one. πŸ‘€

here's the tea on which recipe file types it understands:

  • spec β€” a specfile used to generate rpms. classic. πŸ’–
  • src.rpm β€” a source rpm, which gets unpacked for the build. ✨
  • kiwi β€” a kiwi config file used to generate a kiwi image. πŸ₯
  • dsc β€” a dsc file used to generate Debian binary packages. 🐧
  • PKGBUILD β€” a file used to generate Arch Linux binary packages. btw πŸ¦‹
  • build.collax β€” a shell script used to generate a Collax binary package. ✨

✨ OPTIONS ✨

  • --clean β€” nuke the build system and reinitialize it from scratch. total reset, no leftovers. 🧼
  • --no-init β€” skip the whole build-system initialization thing and just start building immediately. speedrun vibes πŸƒβ€β™€οΈ
  • --repo dir_or_url β€” either a directory holding binary packages (optionally with repository metadata), or a url pointing at some remote repository. you can stack multiple --repo options to create a specific repository layering. heads up tho: packages get searched in the order you specified, so the first repository containing a package with a specific name wins regardless of the version. first come first served, periodt. πŸ’…
    • special form: zypp://reponame specifies a system repository.
    • zypp:// selects all enabled system repositories. this is also the default if BUILD_RPMS is not set and no --rpms or --repo option is used. πŸ‘‘
  • --dist distribution β€” set the distribution. if you don't pass this, build tries to guess the distribution by peeking at the available packages (snoop πŸ‘€). the distribution you specify can be a string like "11.2" or "sles9", "debian7", or the pathname of the build configuration to use.
  • --root buildroot β€” tells you where the build system gets set up. overrides the BUILD_ROOT enviroment variable. 🏠
  • --help β€” print a short help text. the bare minimum bestie 🫢
  • --norootforbuild β€” force building with user abuild. otherwise, build searches the recipe file for a "needsrootforbuild" hint to decide which user to use.
  • --list-state β€” list packages that would be used to create a fresh build root. it does not create the build root or perform a build. window shopping only πŸ›οΈ
  • --rpms path1:path2:path3... β€” where build can find the packages needed to create the build system. this option overrides the BUILD_RPMS environment variable. this option is deprecated, use --repo instead. ⚠️
  • --arch arch1:arch2:arch3... β€” what architectures to select from the RPMs. build automatically sets this to a sensible value for your host if you don't specify it, so you should almost never need it. trust the process πŸ’œ

πŸ”₯ RPM BUILD SPECIFIC OPTIONS πŸ”₯

  • --useusedforbuild β€” tells build not to do dependency expansion, but instead extract the list of packages to install from "# usedforbuild" lines, or β€” if none are found β€” from all "BuildRequires" lines. super handy if you want to re-build a package from a srcrpm with exactly the same packages used for the srcrpm build. no substitutions πŸ’…
  • --stage β€” pass a stage option to rpmbuild. the default is -ba.
  • --target β€” call rpmbuild with a target option. this is the one for cross building. 🌈
  • --verify β€” verify the files in an existing build system. vibe check βœ…

🧚 VIRTUAL MACHINE SPECIFIC OPTIONS 🧚

  • --xen --kvm --uml --qemu --emulator --zvm --lxc β€” sets a specific vm type. pick your fighter πŸ‘‘
  • --vm-type type β€” as above. same energy, different spelling.
  • --vm-disk file β€” specifies the location of the disk image to use. if you don't pass this, buildroot.img is used (e.g. /var/tmp/build-root.img). πŸ’Ύ
  • --vm-disk-size size_in_mb β€” specify the size of the disk image to create. size matters bestie πŸŽ€
  • --vm-disk-filesystem type β€” sets the filesystem type to use when creating the disk image. the default is to use the ext3 filesystem.
  • --vm-swap file β€” specifies the location of the swap file to use. if you don't pass this, buildroot.swap is used (e.g. /var/tmp/build-root.swap).
  • --vm-swap-size size_in_mb β€” specify the size of the swap file to create.
  • --vm-memory size_in_mb β€” sets the desired memory size of the virtual machine. feed her well πŸ“
  • --vm-kernel kernel_file β€” set a specific kernel to boot in the virtual machine.
  • --vm-initrd initrd_file β€” set a specific kernel to boot in the virtual machine. (yes bestie, it says kernel again for the initrd option. we report, we don't editorialize πŸ™ˆ)
  • --vm-disk-clean β€” force the recreation of the disk image. out with the old πŸ’€
  • --vm-telnet PORT β€” is forwarding PORT to a telnet session inside of the VM. specify also needed extra packages via -x parameter, usually:
--vm-telnet 1234 -x telnet-server -x net-tools

and connect from the host via:

telnet localhost 1234
NOTE: The telnet server gets started after all packages got installed. 🫢

πŸ¦‹ RECIPE FILE OPTIONS πŸ¦‹

the build command interprets some special control comments in the recipe file:

  • # norootforbuild
  • # needsrootforbuild

build uses either user root or user abuild in the build system to do the build. for non-SUSE distros as well as since SUSE 10.2, the default build user is abuild. for 10.2 and before, the default build user is root. these two flags in the spec file allow to deviate from the defaults and force-set the build user to abuild and root (for # norootforbuild and # needsrootforbuild respectively.

  • # needsbinariesforbuild β€” provide the binary rpms that have been used to set up the build root in /.build.binaries within the build root. πŸ“¦

🌈 ENVIRONMENT 🌈

  • BUILD_ROOT β€” the directory where build should install the chrooted build system. "/var/tmp/build-root" is used by default. see the --root option. 🏑
  • BUILD_RPMS β€” this can be used instead of the --rpms option. deprecated. ⚠️
  • BUILD_RPM_BUILD_STAGE β€” the rpm build stage (-ba, -bb, ...). this is just passed through to rpm, so check the rpm manpage for a complete list and descriptions. "-ba" is the default. you should probably use the --stage option instead. πŸ’…

⭐ SEE ALSO ⭐


and that's the whole page bestie, you ate that πŸ’– before you go: this gorgeous little BUILD(1) page is brought to you by (c) 1997-2018 SUSE Linux AG Nuernberg, Germany. iconic then, iconic now. now go build something and slay βœ¨πŸ‘‘

πŸ“¦ where this page comes from