EVR: 0.1-1 Lock-SHA256: 61824206677fa4c005c39b36a75626b88c3753fdc00b3cf4110464c85b77e582 Branch: niceos-5.2 |
||
|---|---|---|
| METADATA | ||
| SBOM | ||
| SOURCES | ||
| SPECS | ||
| .gitignore | ||
| OWNERS | ||
| README.md | ||
| README_RU.md | ||
build-essential
Overview
build-essential is a small packaging meta-package used to make a system ready for building software from source. In Debian-derived packaging, it is an informational package that pulls in the core toolchain and related build tools expected on a basic build host. It is mainly useful as a convenience layer for build environments rather than as an application in its own right. (packages.debian.org)
For NiceOS, this package exists to give maintainers and users a consistent starting point for compiling C and C++ software, especially when preparing clean build environments for RPM packaging work. The exact dependency set should always be verified against the package metadata in this repository and the upstream definitions used by the distribution. (packages.debian.org)
Purpose and typical use cases
Typical use cases include:
- preparing a minimal build root before compiling source packages;
- setting up CI jobs that need a predictable toolchain baseline;
- creating developer workstations or containers used for RPM builds;
- ensuring that build-time prerequisites for common native software are present before packaging starts.
Typical users include:
- RPM maintainers;
- build and release engineers;
- CI/CD maintainers;
- developers who compile software locally;
- security or compliance reviewers who want a reproducible build environment.
This package is usually relevant when a workflow needs the basic compiler and build-tool stack, not when a system only runs prebuilt software. (packages.debian.org)
Upstream project
The upstream concept comes from Debian's build-essential package family. Debian describes it as an informational list of packages considered essential for building Debian packages, and notes that the exact definition of "build-essential" comes from Debian Policy rather than from the package itself. (packages.debian.org)
The toolchain pieces commonly associated with this class of package include GCC and related development tools. GCC is the GNU Compiler Collection project maintained by the GNU Project. (gcc.gnu.org)
If NiceOS diverges from Debian's exact package set, maintainers should verify the local policy and the spec file before assuming behavior from the upstream Debian package description. (packages.debian.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 to track imported upstream material;METADATA/— repository metadata used by NiceOS packaging workflows;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 imported sources used to build the package without embedding the full archive content in git. (packages.debian.org)
Source storage and integrity policy
The repository follows a source-metadata model rather than a full source-vendoring model:
- keep the spec file and packaging metadata in git;
- keep source-manifest information in
SOURCES/; - do not add large upstream archives directly to the repository;
- use the manifests to confirm that the imported upstream material matches what the package expects.
For updates, NiceOS maintainers should verify:
- whether the upstream package definition changed;
- whether the list of required build tools still matches distribution policy;
- whether any manifest files in
SOURCES/need regeneration; - whether
SBOM/content, if maintained for this package, needs to be refreshed; - whether any repository metadata in
METADATA/needs to be updated alongside the spec.
If the package is rebuilt from a refreshed upstream list or a new source layout, the maintainer should check that the manifests still describe the intended inputs and that no extra files were introduced accidentally. The precise regeneration steps are repository-specific and should be confirmed in the spec or packaging tooling used by NiceOS. (packages.debian.org)
NiceOS maintenance notes
Before updating this package, check the following:
- confirm the package still serves the same role in NiceOS;
- compare the spec file against the current packaging policy;
- verify that any toolchain dependencies pulled in by the package are still acceptable for the target repositories;
- review whether build-root expectations changed for cross-build or native-build workflows;
- confirm that source manifests in
SOURCES/still match the imported upstream data; - update
SBOM/artifacts if the repository policy requires it; - make sure no generated or temporary packaging files were added to git by mistake.
Risks to consider:
- the package may accidentally depend on a toolchain component that is not intended for the target repository;
- upstream packaging conventions may not match NiceOS conventions exactly;
- any change to the build-tool list can affect CI images, build chroots, and developer workflows;
- if this package is used as part of a standard build environment, changes may have a wide operational impact even when the package itself is small.
If a detail is uncertain, NiceOS maintainers should verify it before relying on it.
Build and verification checklist
For RPM maintainers, a reasonable update checklist is:
- review the spec file for unintended dependency changes;
- ensure the package description still matches the actual build-tool set;
- verify that
SOURCES/manifests are current and complete; - confirm that no large source archives were committed to git;
- build the package in a clean mock or equivalent build root;
- check generated RPM metadata for correctness;
- run dependency and file-list checks for unexpected additions or removals;
- confirm that
SBOM/content, if used, matches the rebuilt package inputs; - compare the resulting package behavior with the previous build to catch accidental changes;
- document any repository-specific regeneration steps needed by the update.
References
- Debian package page for build-essential
- Debian source package page for build-essential
- Debian Policy Manual
- GCC, the GNU Compiler Collection
Russian documentation
See README_RU.md for the Russian version of this document.
Dist-git repository notes
- Package repository:
rpms/build-essential - NiceOS branch:
niceos-5.2 - This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.