RBM-TAR(1)

πŸ“¦
version 0.4^20241205gitc6a4095 Β· 2 versions
, in fedora 43

πŸ’– RBM-TAR πŸ’–

okay so bestie, we're doing rbm-tar(1) today and honestly? it's giving "make me a tarball" energy and I am obsessed πŸ’…


✨ NAME ✨

rbm-tar β€” Create a tarball file πŸŽ€


🌸 SYNOPSIS 🌸

rbm tar <project> [options]

πŸ¦‹ DESCRIPTION πŸ¦‹

So basically: create a tarball file for the selected project. That's it. That's the whole vibe. ✨


πŸŽ€ OUTPUT FILE πŸŽ€

Where does it go? That's the output_dir option's whole job, no cap.

And the filename? It's literally this:

<name>-<version>.tar

but if you set compress_tar, then bestie it becomes:

<name>-<version>.tar.<ext>

Quick legend, iykyk:

  • <name> = the project's name πŸ‘‘
  • <version> = the version of the software 🌈
  • <ext> = the compression type you picked in the compress_tar option πŸ—œοΈ

Also! The version of the software used to create the tarball and the packages should be set with the version option. Don't forget her. πŸ™ˆ


πŸ’œ CONFIGURATION OPTIONS πŸ’œ

These ones are all about the tarball creation, bestie:

  • git_url β€” The URL of a git repository that will be cloned and used to create the tarball. If this option is set, git_hash should be set to select the commit to use. πŸ”₯
  • hg_url β€” The URL of a mercurial repository that will be cloned and used to create the tarball. If this option is set, hg_hash should be set to select the commit to use. 🧚
  • git_hash β€” A git hash, branch name or tag. This is what is used to create the tarball. periodt.
  • hg_hash β€” A mercurial changeset hash. This is what is used to create the tarball. periodt.
  • git_submodule β€” If this option is enabled, git submodules are fetched and included in the tarball. It's disabled by default, fyi. πŸ™ˆ
  • git_depth β€” An integer specifying a depth for shallow Git clone/fetch depth, to decrease network and storage usage. If not set, shallow clone/fetch is disabled. (Saving your wifi and your disk, a public service πŸ’–)
  • git_branch β€” A Git ref name that will be exclusively cloned/fetched, to decrease network and storage usage. Must be a descendent (inclusive) of git_hash. If not set, all Git refs are cloned/fetched. ⭐
  • compress_tar β€” If set, the tarball created will be compressed in the select format. Possible values: xz, gz, bz2, zst. The default is gz but it can stay empty to disable compression. πŸ—œοΈβœ¨
  • commit_gpg_id β€” If set, the commit selected with git_hash will have its signature checked. The tarball will not be created if there is no valid signature, and if the key used to sign it does not match the key ID from commit_gpg_id. The option can be set to a single gpg ID, or to a list of gpg IDs. The IDs can be short or long IDs, or full fingerprint (with no spaces). For this to work, the GPG keys should be present in the selected keyring (see keyring option). If the option is set to 1 or an array containing 1 then any key from the selected keyring is accepted. On command line, the --commit-gpg-id option can be listed multiple times to define a list of keys. πŸ”
  • tag_gpg_id β€” If set, the commit selected with git_hash should be a tag and will have its signature checked. The tarball will not be created if the tag doesn't have a valid signature, and if the key used to sign it does not match the key ID from tag_gpg_id. The option can be set to a single gpg ID, or to a list of gpg IDs. The IDs can be short or long IDs, or full fingerprint (with no spaces). For this to work, the GPG keys should be present in the selected keyring (see keyring option). If the option is set to 1 or an array containing 1 then any key from the selected keyring is accepted. On command line, the --tag-gpg-id option can be listed multiple times to define a list of keys. πŸ”
  • gpg_wrapper β€” This is a template for a gpg wrapper script. The default wrapper will call gpg with the keyring specified by option gpg_keyring if defined. 🫢
  • gpg_keyring β€” The filename of the gpg keyring to use. Path is relative to the keyring directory. This can also be an absolute path. πŸ“
  • gpg_bin β€” The gpg command to be used. The default is gpg. 🧚
  • gpg_args β€” Optional gpg arguments. The default is empty. 🌸
  • gpg_allow_expired_keys β€” Allowing expired keys to successfully verify e.g. signed git tags. By default this is not allowed. ⏰
See rbm_config(7) for all other options. Bestie, that's where the rest of the lore lives πŸ’œ

πŸ’… COMMAND LINE OPTIONS πŸ’…

The command line options related to tar:

  • --git-hash=<hash> β€” The git hash of the commit / tag to use. πŸ”₯
  • --hg-hash=<hash> β€” The mercurial hash of the commit / tag to use. πŸ”₯
  • --commit-gpg-id=<GPG ID> β€” Check the commit to be signed by this GPG key ID. πŸ”
  • --tag-gpg-id=<GPG ID> β€” Check if the selected git hash is a tag and is signed by select GPG key ID. πŸ”
  • --gpg-keyring=<file> β€” GPG keyring filename. πŸŽ€
  • --gpg-keyring-dir=<directory> β€” Directory containing GPG keyring files πŸŽ€
  • --gpg-args=<args> β€” Optional gpg arguments. 🌸
  • --gpg-bin=<path> β€” Path to gpg binary. 🧚
See rbm_cli(7) for all other options. ✨

πŸ‘‘ GIT VERSION πŸ‘‘

Okay so if you're gonna use gpg signed commits, it is recommended to use git >= 1.8.3. Like, strongly. Bestie. Please. 😭

  • git < 1.7.9 does not support signed commits. It only supports signed tags. πŸ’€
  • git < 1.8.3 does not use the git-config option gpg.program in git log --show-signature and git show --show-signatures commands used to check commits signatures. This means you won't be able to use the gpg_keyring option for commits signature verification (but it will work for tag signature verification). This was fixed in git commit 6005dbb9, included in version 1.8.3. πŸ”§

🌈 SEE ALSO 🌈

rbm(1) β€” go read her too, she's iconic πŸ‘‘


and that's the whole page, bestie 🫢 this one's from 07/25/2025, so like, mark your calendar and stan a stable release βœ¨πŸ’–πŸŽ€

πŸ“¦ where this page comes from