State of Packaging (RPM)

[AnthonyZhOon]

Disclaimer: I'm new to packaging

I've been working on producing a .rpm for ghostty and run into a warnings and ambiguous points that would be useful to discuss.

I've got a working .rpm but still have some lints produced by rpmlint to deal with upstream.

Failing rpmlint and warnings

ghostty.x86_64: W: unused-direct-shlib-dependency /usr/bin/ghostty /lib64/ld-linux-x86-64.so.2
$ rpmlint -e unused-direct-shlib-dependency
The binary contains unused direct shared library dependencies.  This may
indicate gratuitously bloated linkage; check that the binary has been linked
with the intended shared libraries only.

I can't find what's causing ghostty to depend on a linker, I think it's not disastrous but it would be nice to fix this warning.

ghostty.x86_64: W: invalid-license Unknown

I've heard that it will be a permissive open-source license, for now I've left this as Unknown.

ghostty.x86_64: E: script-without-shebang /usr/share/ghostty/shell-integration/bash/bash-preexec.sh
ghostty.x86_64: E: script-without-shebang /usr/share/ghostty/shell-integration/elvish/lib/ghostty-integration.elv
ghostty.x86_64: E: env-script-interpreter /usr/share/ghostty/shell-integration/bash/ghostty.bash /usr/bin/env bash

These are inconsistencies in the scripts we distribute, these should be simple fixes and I'll open an issue and pull request to fix these.

Automating releases

I know that the archives at Ghostty Tip ("Nightly) are nightly releases but the file structure of the releases isn't quite what I want for a package source.
On extracting the archive, rpmbuild expects it to extract to a single directory with the version ghostty-0.0.1/ as the top-level directory which contains all the sources instead of having src/ and other files flattened at the top level.

Current archive file structure

./
├── build.zig
├── build.zig.zon
├── .clang-format
├── com.mitchellh.ghostty.yml
├── conformance
├── CONTRIBUTING.md
├── dist
├── .editorconfig
├── .envrc
├── example
├── flake.lock
├── flake.nix
├── .gitattributes
├── .github
├── .gitignore
├── .gitmodules
├── images
├── include
├── macos
├── .mailmap
├── Makefile
├── nix
├── PACKAGING.md
├── pkg
├── .prettierignore
├── README.md
├── README_TESTERS.md
├── shell.nix
├── src
├── test
├── TODO.md
├── typos.toml
├── vendor
└── website

Preferred release archive extract result

ghostty-0.0.1
├── build.zig
├── build.zig.zon
├── .clang-format
├── com.mitchellh.ghostty.yml
├── conformance
├── CONTRIBUTING.md
├── dist
├── .editorconfig
├── .envrc
├── example
├── flake.lock
├── flake.nix
├── .gitattributes
├── .github
├── .gitignore
├── .gitmodules
├── images
├── include
├── macos
├── .mailmap
├── Makefile
├── nix
├── PACKAGING.md
├── pkg
├── .prettierignore
├── README.md
├── README_TESTERS.md
├── shell.nix
├── src
├── test
├── TODO.md
├── typos.toml
├── vendor
└── website

The current state means I unpack the source into a directory, then re-archive it for producing the .rpm.

It's good that the signature for releases is also available to download right next to it.
However the standard signing format is PGP for Debian and Fedora, will other signature methods be supported?

Mysterious configuration

Manpages produced for the system should be gzip'd, and the rpmbuild step does produce .gz manpages with -Demit-docs but when I build ghostty locally by cloning and running the zig build -Doptimize=ReleaseFast -Demit-docs I get raw manpages instead of compressed files.
rpmbuild provides many environment variables that might be configuring this but I'm not sure what exactly flips between the docs build step producing uncompressed or compressed manpages. This would be useful to document and understand for packaging.

Testing

The Fedora Packaging Guidelines mentions running test suites where available. Is this a good idea for packaging Ghostty; is the test-suite feasible to run on install or is there a subset of tests that should be run?

Font Licensing

There are specific font packaging rules for Fedora See Fonts Policy. As Fedora aims to only have open-source licensed packages in the official package repository (I'm not sure if I'll proceed with adding to the main repos), I'm not 100% clear on where the compiled-with fonts lie.

I can't find licensing or attribution for the fonts that come bundled with Ghostty. Checking out JetBrains Mono which uses the Open Font License I notice a few points we don't address.

2. Original or Modified Versions of the Font Software may be bundled,
   redistributed and/or sold with any software, provided that each copy
   contains the above copyright notice and this license. These can be
   included either as stand-alone text files, human-readable headers or
   in the appropriate machine-readable metadata fields within text or
   binary files as long as those fields can be easily viewed by the user.

5. The Font Software, modified or unmodified, in part or in whole,
   must be distributed entirely under this license, and must not be
   distributed under any other license. The requirement for fonts to
   remain under this license does not apply to any document created
   using the Font Software.

Build Options in PACKAGING.md

I've used -Dcpu=baseline and -Dpie, however -Dpie isn't documented in PACKAGING.md yet and I can open a issue + PR for this.

I noticed rpmbuild exports build flags for C++ and less for Rust, these are related to performance and safety.

+ CXXFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
+ export CXXFLAGS

+ RUSTFLAGS='-Copt-level=3 -Cdebuginfo=2 -Ccodegen-units=1 -Cstrip=none -Cforce-frame-pointers=yes -Clink-arg=-specs=/usr/lib/rpm/redhat/redhat-package-notes --cap-lints=warn'
+ export RUSTFLAGS

A couple that I notice are related to

• debuginfo (I've not packaged any debuginfo and had to disable it to have builds succeed, but I believe this is important to package)
  • strip
  • -fno-omit-frame-pointer
  • -g (debug info for C++)
• stack protection and hardening
• performance
  • lto (Link Time Optimisation)
  • Codegen units
• Adding package metadata at link time, /usr/lib/rpm/redhat/redhat-package-notes contains

*link:
+ --package-metadata={\"type\":\"rpm\",\"name\":\"%:getenv(RPM_PACKAGE_NAME \",\"version\":\"%:getenv(RPM_PACKAGE_VERSION -%:getenv(RPM_PACKAGE_RELEASE \",\"architecture\":\"%:getenv(RPM_ARCH \",\"osCpe\":\"cpe:/o:fedoraproject:fedora:41\"}))))

Do we have reliable defaults here in Zig, or should more configuration options be exposed for packaging purposes? I haven't figured out how to produce debuginfo packages for RPM yet so help there would be nice, relevant docs are Check your debuginfo is useful.

[AnthonyZhOon]

I found why manpages get compressed in the build, this is a feature of the rpmbuild install stage.

Manpages

As man pages are the traditional method of getting help on a Unix system, packages SHOULD contain them for all executables. If some man pages are absent, packagers SHOULD work with upstream to add them. It is also occasionally possible to find pages created by other distributions, or to use the output of the help2man program; those are often useful as a starting point. When installing man pages, note that RPM will re-compress them into its preferred format. So the %files section MUST reference manpages with a pattern that takes this into account:

%files
%{_mandir}/man1/foo.1*

Note also that files installed in %{_mandir} are automatically marked by RPM as documentation. Thus it is not necessary to use %doc.

For localised manpages, use %find_lang --with-man as described in Handling Locale Files.

So automatic compression is rpmbuild specific

[mitchellh]

I'll take a closer to look at each thing later but thanks for putting this together!

[mitchellh]

Breaking these out to separate threads. First up:

However the standard signing format is PGP for Debian and Fedora, will other signature methods be supported?

I'm not planning on it. Minisign is super easy and I feel at this point fairly well trusted and used. Let's see what happens.

[mitchellh]

On extracting the archive, rpmbuild expects it to extract to a single directory with the version ghostty-0.0.1/ as the top-level directory which contains all the sources instead of having src/ and other files flattened at the top level.

Yeah, I think this is pretty standard. Do you know what the required format is for things like nightly releases? Once I know that, I can open an issue to plan this.

[AnthonyZhOon]

I'm not sure if there's something completely standard but searching "nightly" at pkgs.org shows a few examples.

• zed-nightly-0:0.160.0^20241026.d7a2776-1.fc41.x86_64.rpm
• yt-dlp-nightly-0:20241008.git~983c58f-1.fc41.noarch.rpm
  • Releases at https://github.com/yt-dlp/yt-dlp-nightly-builds/releases
    https://github.com/yt-dlp/yt-dlp-nightly-builds/releases/download/2024.11.15.232903/yt-dlp.tar.gz

While the tar archive doesn't change, the each nightly release is a new link that has the date included

[mitchellh]

The Fedora Packaging Guidelines mentions running test suites where available. Is this a good idea for packaging Ghostty; is the test-suite feasible to run on install or is there a subset of tests that should be run?

The test suite is feasible to run, zig build test and away you go. Up to packagers if they want to do that.

[mitchellh]

There are specific font packaging rules for Fedora See Fonts Policy. As Fedora aims to only have open-source licensed packages in the official package repository (I'm not sure if I'll proceed with adding to the main repos), I'm not 100% clear on where the compiled-with fonts lie.

I can't find licensing or attribution for the fonts that come bundled with Ghostty. Checking out JetBrains Mono which uses the Open Font License I notice a few points we don't address.

I think we need to add the font license to the repo but are otherwise in compliance. We don't modify the fonts. And the only embedded font is JB Mono. The rest that are in the repo are only used for tests (but we should include their licenses as well, I made sure when adding them that they're all OFL).

[mitchellh]

#2686