debugedit

Overview

debugedit is a Sourceware project that provides programs and scripts for working with debugging data in ELF files. Upstream describes it as a toolset for creating debuginfo and source file distributions, collecting build IDs, and rewriting source paths in DWARF data for debugging, tracing, and profiling. (sourceware.org)

In a Linux distribution, this package is typically part of the build and packaging toolchain rather than an end-user application. Maintainers and build systems use it when generating debug information and preparing source-path metadata for packaged binaries. That role should be verified against the distribution’s packaging rules if NiceOS changes how debuginfo or build-id processing is handled. (sourceware.org)

Purpose and typical use cases

Typical use cases include:

• rewriting source paths recorded in DWARF data so debug symbols refer to the packaged source layout;
• helping build systems collect build IDs during package builds;
• preparing debuginfo and source file distributions for ELF binaries;
• supporting trace and profiling workflows that depend on accurate debug metadata. (sourceware.org)

Typical users are:

• RPM and distro package maintainers;
• build and release engineers;
• CI/CD maintainers who produce reproducible or debuginfo-enabled builds;
• developers working on packaging, debug info, or ELF/DWARF tooling;
• security and incident-response engineers who inspect debug metadata and build IDs. The exact workflow depends on the distribution and should be verified by NiceOS maintainers for their environment. (sourceware.org)

Upstream project

Upstream is hosted by Sourceware. The project page, source repository, and release area are published there. Upstream also states that the code depends on elfutils libelf and libdw to read and write ELF files, DWARF data, and build IDs. (sourceware.org)

Canonical upstream references:

• project page: https://sourceware.org/debugedit/
• source repository: https://sourceware.org/git/debugedit.git
• releases: https://sourceware.org/pub/debugedit/ (sourceware.org)

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic;
• SOURCES/ — source metadata and manifests used by the RPM build process;
• METADATA/ — repository metadata used by tooling and package indexing;
• SBOM/ — software bill of materials data, if present for this package.

Large upstream source archives are intentionally not stored in this Git repository. Instead, source integrity is tracked through manifest files in SOURCES/, which record the expected source set for the build. The exact manifest format may vary by package tooling, so NiceOS maintainers should verify the local workflow before relying on it.

Source storage and integrity policy

This repository follows a source-management model where Git stores packaging metadata rather than full upstream source tarballs. That keeps the dist-git tree small and reviewable while still allowing the build system to verify which sources belong to the package.

Before updating the package, maintainers should check that:

• the upstream source set still matches the manifests in SOURCES/;
• any new or removed upstream files are reflected in packaging metadata;
• no generated files or local-only artifacts were accidentally added to the source set;
• repository metadata in METADATA/ remains consistent with the package structure;
• any SBOM content in SBOM/ still describes the shipped build correctly, if that directory is used here.

NiceOS maintenance notes

Before submitting an update, NiceOS maintainers should review:

• upstream release notes, if available, for changes that could affect debug-info rewriting or build tooling;
• packaging diffs in the spec file for new build dependencies, configure options, or file list changes;
• any generated files that may need to be refreshed during the update;
• whether build or test expectations changed in the upstream build system;
• whether the update affects debuginfo generation, build-ID handling, or source-path rewriting in a way that could impact other packages. Upstream has previously discussed build-related changes around inlined xxhash handling, so build configuration should be checked carefully when the toolchain changes; maintainers should verify the current behavior upstream before assuming it is unchanged. (sourceware.org)

Practical risks to consider:

• changes in upstream build scripts that affect reproducible packaging;
• new generated files that should not be committed to dist-git;
• altered paths or install locations that may break file ownership or scriptlets;
• dependency drift in ELF/DWARF support libraries;
• mismatches between packaging metadata and the actual source set.

Build and verification checklist

For an RPM update, a maintainer should usually verify:

1. The spec file still matches the upstream build system.
2. SOURCES/ manifests match the intended upstream source set.
3. rpmbuild or the distro build system succeeds in a clean environment.
4. Installed files match the spec file’s %files section.
5. Build-time dependencies are complete and minimal.
6. The package still produces the expected binaries and scripts.
7. If applicable, package tests or smoke tests run successfully.
8. The resulting package still behaves correctly in debuginfo or build-ID workflows.
9. METADATA/ and SBOM/ are updated only when required by local policy.
10. No generated or machine-local artifacts were accidentally committed.

If the package has downstream patches or local packaging adjustments, review them against the new upstream version before merging.

References

• debugedit project page
• debugedit source repository
• debugedit releases
• Sourceware projects directory

Russian documentation

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

Dist-git repository notes

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