cairo

Overview

Cairo is a 2D graphics library used by applications that need consistent drawing across multiple output targets. Upstream describes it as a C library with support for devices such as X Window System, image buffers, PostScript, PDF, SVG, Quartz, and Win32 backends. It is widely used as a rendering layer by desktop software, document tools, GUI toolkits, and other programs that need vector drawing, text rendering, transforms, and compositing. (cairographics.org)

In a Linux distribution, the cairo package typically provides the shared library and related files needed by other packages at build time and run time. NiceOS maintainers should verify the exact packaging split in this repository and in the generated RPMs before relying on any particular subpackage layout.

Purpose and typical use cases

Typical use cases include:

• desktop and GUI applications that draw shapes, text, and images through a common 2D API;
• rendering to screen, print, or file formats such as PDF, PostScript, and SVG;
• software stacks that need a portable graphics layer rather than backend-specific drawing code;
• language bindings and frameworks that expose cairo to higher-level toolkits;
• build and CI environments that need the development headers and pkg-config metadata for dependent packages.

Typical users include:

• desktop application maintainers and toolkit integrators;
• distribution packagers and RPM maintainers;
• developers working on graphics-enabled applications;
• CI/CD maintainers who verify build-time dependencies;
• security or hardening engineers who review native libraries and their update impact.

Upstream project

Upstream is the cairo graphics project. The official site and primary documentation describe the project, its API manual, tutorial, and download area. The main project home is the canonical reference point for upstream purpose and documentation. (cairographics.org)

Useful upstream documentation pages include:

• project home and summary;
• API manual;
• tutorial;
• documentation index.

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic;
• SOURCES/ — source metadata and manifest files used to track upstream inputs;
• METADATA/ — repository metadata used by the packaging workflow;
• SBOM/ — software bill of materials material, when maintained for this package.

The repository is meant to track packaging state, not to mirror all upstream source archives.

Source storage and integrity policy

Large upstream source archives are intentionally not stored in this Git repository. Instead, source integrity is tracked through manifest files in SOURCES/.

For maintainers, this means:

• check that the manifests match the intended upstream source inputs before updating;
• do not assume the repository contains the full upstream tarball history;
• verify that any regenerated manifest files correspond to the exact source material used for the build;
• review whether auxiliary generated files need to be refreshed alongside the spec update.

Do not rely on hardcoded digests in documentation; they change with upstream updates and are intentionally omitted here.

NiceOS maintenance notes

Before updating cairo, NiceOS maintainers should check:

• whether upstream changed build system behavior, optional features, or documentation layout;
• whether the spec file needs updates for new files, renamed artifacts, or changed install paths;
• whether source manifests in SOURCES/ need regeneration;
• whether SBOM/ or other metadata files need a refresh;
• whether downstream patches still apply cleanly or should be dropped;
• whether dependent packages may need rebuilds because of ABI, API, or soname changes;
• whether the update changes build requirements or test expectations.

Recommended risk review:

• confirm that any packaging changes preserve the intended library split;
• check for accidental inclusion or omission of docs, examples, or helper files;
• verify that build flags and optional backends still match NiceOS policy;
• review changelogs or release notes for compatibility-impacting changes;
• if anything is unclear, NiceOS maintainers should verify it before relying on it.

Build and verification checklist

For RPM maintenance, a practical check sequence is:

1. Review the spec diff for packaging changes.
2. Confirm the SOURCES/ manifest update matches the new upstream input.
3. Check that SPECS/ still installs the intended files into the expected subpackages.
4. Build the package in a clean mock or equivalent build root.
5. Run the package test suite if upstream provides one and if it is enabled in the spec.
6. Inspect build logs for missing dependencies, disabled features, or unexpected warnings.
7. Verify the generated RPM payloads, file lists, and dependencies.
8. Check that the library and development packages are both present if required by downstream consumers.
9. If the update changes ABI or linked behavior, rebuild reverse dependencies or at least identify affected packages.
10. Review the resulting SBOM/ or metadata updates if your workflow uses them.

References

• Cairo project home
• Cairo documentation index
• Cairo API manual
• Cairo tutorial
• Cairo download page

Russian documentation

See README_RU.md for the Russian version of this document.

Dist-git repository notes

• Package repository: rpms/cairo
• NiceOS branch: niceos-5.2
• This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.