basic

Overview

basic is a core NiceOS package intended to provide the baseline system components that other parts of the distribution expect to find. The upstream NiceOS package page describes it as a system foundation package that supplies essential utilities and libraries for the operating system. NiceOS maintainers should verify the exact upstream payload when updating this package, because the practical contents may change over time. (z.niceos.ru)

Purpose and typical use cases

This package exists to support the usable base of the distribution rather than a single application. Typical use cases include:

• providing the minimum userspace expected by other packages and system tools;
• supporting administrative tasks on installed systems;
• supplying foundational files or helpers needed during boot, login, or package operations;
• acting as part of a controlled distribution base image or system profile.

Typical users are system administrators, distro maintainers, CI/CD maintainers, and developers who work on base system images or package integration. Desktop users usually benefit indirectly through the packages and services that depend on this base layer. The exact dependency chain should be checked in the repository metadata before assuming a specific role. (z.niceos.ru)

Upstream project

The upstream project is maintained by NiceOS. The public NiceOS site presents NiceOS as a Linux distribution for infrastructure, security, containers, and protected environments, with a controlled base system and documented package catalog. For this package, the package page is the main upstream reference available from the public site. Maintainers should confirm any finer-grained upstream details directly from the package metadata or source tree before relying on them. (niceos.ru)

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and package policy material;
• SOURCES/ — source manifests and other source-control metadata used to describe what must be fetched for builds;
• METADATA/ — repository metadata used by the packaging workflow;
• SBOM/ — software bill of materials material, if present for the package workflow.

Large upstream source archives are intentionally not stored in this Git repository. Instead, the repository keeps the metadata needed to reproduce and verify the source set during packaging. (z.niceos.ru)

Source storage and integrity policy

The source policy for this package is to keep source integrity tracked through manifest files in SOURCES/, not by committing large upstream archives into Git. This keeps the repository lightweight and makes it easier to review packaging changes without carrying binary or bulky upstream payloads in version control.

Before updating the package, NiceOS maintainers should verify that:

• the source manifest still points to the intended upstream content;
• any new upstream archive or generated file is reflected in the manifest set;
• files in SOURCES/ remain consistent with the spec file expectations;
• no unintended source replacement, missing file, or packaging drift was introduced.

Do not rely on cached assumptions from previous versions; always re-check the current manifests and upstream release material. (z.niceos.ru)

NiceOS maintenance notes

Before changing this package, maintainers should review:

• whether the upstream package page or source set changed in a way that affects the packaged payload;
• whether the spec file needs refreshes in build logic, file lists, or installed paths;
• whether SOURCES/ manifests need regeneration;
• whether SBOM/ material, if used in this repository, needs to be updated for the new source set;
• whether the package still belongs to the same role in the NiceOS base system.

Risks to consider:

• the package may contain files that are implicitly required by other packages;
• changes in file layout can break bootstrapping, system integration, or dependent scripts;
• source manifest drift can cause builds to consume the wrong upstream content;
• base packages deserve extra caution because small changes can have broad system impact.

If the upstream purpose or file set is unclear, NiceOS maintainers should verify it before treating the update as routine. (z.niceos.ru)

Build and verification checklist

For RPM maintenance, a practical review usually includes:

• confirm the spec file parses cleanly;
• confirm the source manifests in SOURCES/ match the intended upstream inputs;
• verify any regenerated metadata or SBOM material is up to date;
• run a local build in the expected NiceOS build environment;
• inspect build logs for missing files, changed paths, or dependency issues;
• review the resulting RPM payload and file ownership;
• check that no unexpected runtime requirements or packaging splits were introduced;
• install or upgrade-test the package in a clean test root or VM when practical;
• confirm dependent packages or system components still work as expected.

For a base package, also check whether the update changes any assumptions made by installer images, system profiles, or bootstrap workflows. (niceos.ru)

References

• NiceOS homepage
• NiceOS package page for basic
• NiceOS documentation portal

Russian documentation

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

Dist-git repository notes

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