7zip

Overview

7-Zip is an upstream file archiver project. Its official site describes it as a file archiver with a high compression ratio, and it provides both graphical and command-line tooling. In a Linux distribution, the package is useful when users or automation need to create, inspect, test, or extract archive files in formats supported by 7-Zip. (7-zip.org)

For NiceOS, this package exists to make the upstream archiver available in a distribution-managed form, with packaging, rebuildability, and update handling managed in dist-git instead of by ad hoc local copies. The exact integration details in the distribution may differ, so NiceOS maintainers should verify any distro-specific behavior before relying on it.

Purpose and typical use cases

Typical uses include:

• unpacking archives received from users, vendors, build systems, or CI jobs
• repackaging files into archives for transfer or release workflows
• validating archives during maintenance or incident response work
• scripting archive operations in automation and CI/CD pipelines
• handling archive formats that are commonly exchanged across platforms

Typical users include:

• system and release administrators who need archive tools for packaging workflows
• developers who need command-line archive handling in build or test jobs
• CI/CD maintainers who validate or repack artifacts
• security engineers or incident responders who inspect archive payloads during analysis
• desktop users who need a GUI or command-line archiver for everyday file exchange

Upstream project

The upstream project is 7-Zip. The official project site and FAQ describe it as free software, with most code under LGPL, some parts under BSD 3-Clause, and some code under an unRAR-related restriction for specific components. NiceOS maintainers should verify the packaging license expression against the current source tree before any license-related change. (7-zip.org)

The upstream documentation also provides support and recovery guidance, including FAQ material and instructions for reporting issues. For packaging work, these pages are useful as reference material when checking whether a change is upstream behavior or a packaging issue. (7-zip.org)

Dist-git repository contents

This dist-git repository is organized as a standard RPM packaging repository:

• SPECS/ — RPM spec files and packaging logic
• SOURCES/ — source manifests and related integrity metadata
• METADATA/ — repository metadata used by the packaging workflow
• SBOM/ — software bill of materials data, when present in the packaging process

The repository stores packaging metadata, not the full upstream source archive contents. Large upstream source archives are intentionally not kept in Git here; instead, source integrity is tracked through manifest files in SOURCES/.

Source storage and integrity policy

The source handling policy for this package is simple:

• upstream source archives are obtained outside this Git repository
• SOURCES/ contains the manifest information needed to identify and verify the expected source payloads
• the manifests are the authoritative packaging reference inside dist-git
• maintainers should not expect large upstream archives to appear in commit history

Before updating the package, NiceOS maintainers should check that the manifests still match the upstream source being packaged and that any auxiliary files referenced by the spec are accounted for. If any source file layout changes upstream, the repository may need refreshed manifest data or packaging adjustments.

NiceOS maintenance notes

Before accepting an update, check the following:

• compare upstream changes against the current spec file and patch set
• review whether any files in SPECS/, SOURCES/, METADATA/, or SBOM/ need regeneration
• confirm that the source manifests in SOURCES/ still describe the intended input files
• verify whether upstream changed build instructions, bundled components, or file installation paths
• check whether the license classification in the spec still matches the upstream source tree
• review whether any downstream patch can be dropped, refreshed, or needs a follow-up fix
• consider whether new upstream behavior changes archive compatibility, command-line flags, or packaging assumptions

Risks to consider:

• upstream source layout changes may break spec logic or source manifests
• bundled library or component changes may affect licensing review
• build system changes may require spec refreshes or new BuildRequires
• behavior changes in archive handling may affect tests, scripts, or user expectations

If any of these points is uncertain, NiceOS maintainers should verify it before relying on the update.

Build and verification checklist

For RPM maintenance, a practical checklist is:

• inspect the spec diff before importing a new upstream release
• confirm that the source manifest update is intentional and complete
• run a local build in a clean mock or equivalent build environment
• review build logs for new warnings, missing files, or unexpected test failures
• check that installed files land in the expected paths
• verify that package ownership, licenses, and documentation files are still correct
• run any available upstream or downstream smoke tests for archive create/extract behavior
• confirm that the resulting RPMs satisfy repository policy before pushing

If the package has no automated test suite in the distro packaging context, maintainers should at least perform a basic install-and-run check and validate a simple archive operation.

References

• 7-Zip official website
• 7-Zip FAQ
• 7-Zip technical support
• 7-Zip download information
• How to recover corrupted 7z archive

Russian documentation

• README_RU.md

Dist-git repository notes

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