# Sumi as an RPM, for Fedora COPR.
#
# Built and tested in the project's Fedora VM before it was ever
# uploaded -- see docs/distribution.md. The Homebrew release taught
# this the expensive way: a packaging path that has not been walked
# end to end is a packaging path that does not work.
#
# ## Why the sources are vendored
#
# COPR builds in mock, and mock has **no network**. `cargo build` would
# try to fetch every dependency from crates.io and fail. The source
# tarball therefore carries `vendor/` -- the output of `cargo vendor` --
# and `.cargo/config.toml` redirecting crates.io to it, so the build is
# offline by construction rather than by hoping.
#
# This is why Source0 is built by tools/rpm_source.sh and is not a
# plain `git archive`.
#
# ## Why not rust2rpm
#
# Fedora's own way is one RPM per crate, which is right for a library
# that other packages link. Sumi is a leaf application with a few
# hundred transitive dependencies; packaging each would be months of
# work for no one's benefit. Vendoring is what Fedora itself does for
# leaf Rust applications of this size.

Name:           sumi
Version:        0.1.0
Release:        1%{?dist}
Summary:        PDF viewer and editor
Summary(de):    PDF-Betrachter und -Editor

License:        Apache-2.0
URL:            https://git.vonar.ch/maettu/sumi-release
Source0:        %{name}-%{version}.tar.gz

# The engine is written from scratch -- no PDF library, no rendering
# library -- so the build needs a Rust toolchain and GTK, and nothing
# else. gtk4 >= 4.21 and libadwaita >= 1.9 are relm4's gnome_50
# feature's floor; see docs/building-linux.md.
BuildRequires:  rust >= 1.80
BuildRequires:  cargo
BuildRequires:  gcc
BuildRequires:  pkgconfig(gtk4) >= 4.21
BuildRequires:  pkgconfig(libadwaita-1) >= 1.9
BuildRequires:  desktop-file-utils
BuildRequires:  appstream

# Apple silicon and x86_64 both; the engine has no assembly.
ExclusiveArch:  %{rust_arches}

%description
Sumi reads, annotates and edits PDF documents. Its engine is written
from scratch against ISO 32000-1 -- it uses no PDF library for
parsing, writing, rendering or signing -- and it carries the fourteen
standard fonts the specification requires a conforming reader to
provide.

%description -l de
Sumi liest, kommentiert und bearbeitet PDF-Dokumente. Der Motor ist von
Grund auf gegen ISO 32000-1 geschrieben und benutzt keine
PDF-Bibliothek, weder zum Lesen noch zum Schreiben, Zeichnen oder
Signieren. Die vierzehn Standardschriften, die die Norm von einem
konformen Betrachter verlangt, sind mitgeliefert.

%prep
%autosetup -n %{name}-%{version}

%build
# Offline, against the vendored tree the tarball carries. Release and
# not debug: the renderer rasterises pages, and an unoptimised build of
# that is slow enough to feel broken.
cargo build --release --offline -p pdf_gui

%install
install -Dpm0755 target/release/pdf_gui %{buildroot}%{_bindir}/%{name}

# The desktop entry is a template whose @BINARY@ is the installed path.
# A packaged entry names the command on PATH, unlike the one
# `--install-desktop-entry` writes for a build out of target/, which
# carries an absolute path because there is no installation tree.
sed -e 's|@BINARY@|%{_bindir}/%{name}|g' \
    pdf_gui/data/ch.vonar.Sumi.desktop.in \
    > %{buildroot}/ch.vonar.Sumi.desktop.tmp
install -Dpm0644 %{buildroot}/ch.vonar.Sumi.desktop.tmp \
    %{buildroot}%{_datadir}/applications/ch.vonar.Sumi.desktop
rm -f %{buildroot}/ch.vonar.Sumi.desktop.tmp

install -Dpm0644 pdf_gui/data/ch.vonar.Sumi.svg \
    %{buildroot}%{_datadir}/icons/hicolor/scalable/apps/ch.vonar.Sumi.svg
install -Dpm0644 pdf_gui/data/ch.vonar.Sumi.metainfo.xml \
    %{buildroot}%{_metainfodir}/ch.vonar.Sumi.metainfo.xml

%check
# Both of these have caught a real mistake in this project before: a
# desktop entry the shell silently ignores, and metadata GNOME Software
# refuses. They cost a second and they fail the build, which is the
# point -- a package that installs and then does not appear is the
# worst outcome.
desktop-file-validate %{buildroot}%{_datadir}/applications/ch.vonar.Sumi.desktop

# `appstreamcli` from the appstream package, and **not**
# `appstream-util` from libappstream-glib, which is what this line
# said until 2026-10-12.
#
# They disagree, and the lenient one was the one being trusted. The
# metainfo file spent several hours containing `--` inside an XML
# comment, which XML 1.0 section 2.5 forbids outright. Measured on that
# file:
#
#   appstream-util validate       --nonet   -> OK, exit 0
#   appstream-util validate-relax --nonet   -> OK, exit 0
#   appstreamcli   validate       --no-net  -> E: xml-markup-invalid, exit 3
#   python3 -c "xml.etree.ElementTree.parse(...)" -> ParseError
#
# appstream-util parses with GMarkup, which is forgiving. appstreamcli
# parses with libxml2, which is what GNOME Software and every
# distribution's catalogue generator actually use -- so the build was
# green on a file no conformant parser could read, and the catalogue
# would have dropped the component in silence. Sumi would simply never
# have appeared in a software centre, which is the one failure this
# check exists to prevent.
#
# A guard that cannot fail is worse than no guard, because it is
# believed. See CLAUDE.md, "Instruments lie in one direction".
appstreamcli validate --no-net \
    %{buildroot}%{_metainfodir}/ch.vonar.Sumi.metainfo.xml

%files
%license LICENSE
%doc NOTICE
%{_bindir}/%{name}
%{_datadir}/applications/ch.vonar.Sumi.desktop
%{_datadir}/icons/hicolor/scalable/apps/ch.vonar.Sumi.svg
%{_metainfodir}/ch.vonar.Sumi.metainfo.xml

%changelog
* Mon Oct 12 2026 Matthias von Arx <account@ledi.ch> - 0.1.0-1
- First package.