chkconfig

Overview

chkconfig is a system tool for managing the traditional /etc/rc*.d service start-up hierarchy. In practical terms, it helps systems that still use SysV-style init scripts or compatibility layers keep service enablement consistent across runlevels. The upstream project describes it as a tool for maintaining the /etc/rc*.d hierarchy. (github.com)

In a Linux distribution, this package exists to provide the command-line tooling and package integration needed by older init-script-based software and by systems that still rely on SysV compatibility behavior. If the distribution or a package uses systemd-only management, the exact role of chkconfig may be smaller, so NiceOS maintainers should verify the actual packaging use case before changing assumptions.

Purpose and typical use cases

Typical use cases include:

• enabling or disabling legacy services at boot
• inspecting how init scripts are registered for runlevels
• supporting packages that still install SysV init scripts or compatibility links
• maintaining environments that mix newer service managers with legacy service-control conventions

Typical users include:

• distribution maintainers packaging legacy service scripts
• system administrators working with older boot-time service management
• CI/CD or image-build maintainers validating package installation behavior
• developers who need to test compatibility with SysV-style service setup

Upstream project

Upstream is hosted at the project repository on GitHub. The repository title and README identify the project as a system tool for maintaining the /etc/rc*.d hierarchy. The repository also contains man pages, source files, tests, and packaging-related files. (github.com)

Before relying on upstream behavior, NiceOS maintainers should verify the current upstream branch, release state, and any packaging or build changes that may affect the downstream spec.

Dist-git repository contents

This NiceOS dist-git repository is organized as follows:

• SPECS/ — RPM spec files and related packaging logic
• SOURCES/ — source metadata and manifests used to track what should be fetched for builds
• METADATA/ — repository metadata used by the packaging workflow
• SBOM/ — software bill of materials materials, when present for the package workflow

This layout is intended to keep the Git history small and focused on packaging changes rather than storing all upstream source content directly in the repository.

Source storage and integrity policy

Large upstream source archives are intentionally not stored in this Git repository. Instead, the repository records source integrity through manifest files in SOURCES/.

For maintainers, this means:

• the repo should contain the tracking metadata needed to reproduce the source set
• source updates should be reflected in the manifest files rather than committed as large binary blobs
• any mismatch between the manifest and fetched upstream content should be treated as a packaging issue to investigate before a build is accepted

NiceOS maintainers should verify the exact source-management workflow used by this branch before publishing updates.

NiceOS maintenance notes

Before updating the package, check at least the following:

• whether upstream changed build requirements, install paths, or man pages
• whether the spec file still matches the current upstream layout
• whether any SOURCES/ manifest needs regeneration after source changes
• whether SBOM/ data, if used for this package, needs to be refreshed
• whether downstream patches are still needed or should be dropped
• whether legacy SysV assumptions still match the intended use on NiceOS

Risks to consider:

• changes in upstream init-script handling may affect boot-time service management
• packaging-only changes may break compatibility with scripts that expect older behavior
• refreshed source metadata may expose missing or stale entries in SOURCES/

If any detail is uncertain, NiceOS maintainers should verify it against the current upstream tree and the local build logs before merging the update.

Build and verification checklist

For an RPM update, a maintainer should usually check:

• spec file syntax and macro usage
• %prep, %build, %install, and file lists for consistency with upstream
• that the source manifest in SOURCES/ matches the intended source set
• that generated files, if any, are regenerated or removed as appropriate
• that man pages and installed paths match the packaging expectations
• that no unexpected files are introduced into the build root
• that package tests, if available, still pass in the build environment
• that the resulting RPM installs cleanly and provides the expected commands and files

A minimal verification flow is:

1. review the diff in SPECS/ and SOURCES/
2. build in a clean mock or equivalent isolated environment
3. inspect the build log for missing build dependencies or file conflicts
4. install the RPM into a test environment
5. confirm the expected binaries and man pages are present
6. if the package affects service registration, verify the runtime behavior on the target init system

References

• Upstream repository

Russian documentation

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

Dist-git repository notes

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