chrpath

Overview

chrpath is a small utility for inspecting and changing the runtime library search path recorded in ELF executables and shared libraries. In practical terms, it is used when a packaged binary carries an embedded RPATH or RUNPATH value that needs to be removed or adjusted before the software is shipped in a Linux distribution. The upstream manual describes it as a tool for modifying the dynamic library load path of compiled programs. (freshports.org)

For a distribution package, that usually makes chrpath a build-time or maintenance-time tool rather than a user-facing desktop application. It is most often relevant when packaging third-party binaries, cleaning up build artifacts, or fixing path handling in software that is not fully relocatable. (freshports.org)

Purpose and typical use cases

Typical use cases include:

• removing an embedded runtime path from an ELF binary;
• replacing one runtime search path with another;
• checking whether a binary still carries an RPATH or RUNPATH entry;
• reviewing packaged binaries before they are included in a distribution build.

The tool works on existing ELF files and edits the path in place, so maintainers should verify that the replacement path fits the space available in the original entry. If a packaging workflow depends on a longer replacement path, NiceOS maintainers should verify that the update is still safe before relying on it. (freshports.org)

Typical users are:

• RPM and distro package maintainers;
• build and release engineers;
• developers packaging upstream binaries for Linux;
• CI/CD maintainers running binary hygiene checks;
• security or compliance reviewers who inspect embedded runtime paths during packaging.

Upstream project

The historical project homepage listed for this package is https://alioth.debian.org/projects/chrpath/, but that page should be treated as historical metadata and verified before relying on it. A more current upstream project reference used by package tracking is the Codeberg project https://codeberg.org/pere/chrpath/. chrpath is documented in the Debian manpages set as a tool to modify the runtime search path in existing ELF binaries. (release-monitoring.org)

Dist-git repository contents

This NiceOS dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic;
• SOURCES/ — source manifests and related metadata used by the package build;
• METADATA/ — repository metadata consumed by packaging tooling;
• SBOM/ — software bill of materials material, when present for the package.

The repository intentionally does not store large upstream source archives. Instead, source integrity is tracked through manifest files in SOURCES/. That keeps the Git history smaller and lets maintainers review what source material is expected without committing bulky archives into the repository. (man7.org)

Source storage and integrity policy

For this package, the source policy is to keep large upstream archives out of Git and record the expected source material in SOURCES/ manifests. Maintainers should treat those manifests as the authoritative reference for what the build expects to fetch or verify.

Before updating the package, verify that:

• the SOURCES/ manifest still matches the intended upstream source set;
• the spec file still refers to the correct source layout;
• no extra source blobs were accidentally added to the repository;
• any generated packaging metadata still reflects the current upstream release structure.

If the update changes the upstream archive layout, checksum references, or source naming, NiceOS maintainers should regenerate the affected manifest or metadata files as needed. Do not assume the previous packaging metadata remains valid after a source format change. (man7.org)

NiceOS maintenance notes

Before updating chrpath, check the following:

• confirm the upstream project location and release source are still current;
• review whether the package still needs any downstream patches;
• check whether the RPM spec expects a particular build system or test layout;
• verify whether SOURCES/ or other generated metadata must be refreshed;
• confirm that the packaged binary still behaves correctly on NiceOS toolchains and ELF handling.

Main risks to consider:

• embedded path editing can fail if a requested replacement does not fit the existing field;
• packaging may break if upstream changes filenames, build scripts, or install layout;
• changes in the upstream project location may make older homepage metadata stale.

If any of these details are uncertain, NiceOS maintainers should verify them before relying on the package update.

Build and verification checklist

Use this checklist when preparing an RPM update:

1. Review the spec file for source and patch changes.
2. Confirm the SOURCES/ manifest still matches the expected upstream input.
3. Rebuild the SRPM locally.
4. Build the binary RPM in a clean mock or equivalent build environment.
5. Inspect the build log for warnings or unexpected file installs.
6. Run package sanity checks, including file ownership, permissions, and installed paths.
7. If the package ships a man page or documentation, verify it is installed correctly.
8. Test the tool on a representative ELF binary and confirm the output matches expectations.
9. Check whether any downstream patches still apply cleanly and remain necessary.
10. Review the resulting RPM payload for unwanted files or missing documentation.

References

• Upstream project homepage
• Current upstream project page
• Debian manpages: chrpath

Russian documentation

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

Dist-git repository notes

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