bridge-utils

Overview

bridge-utils provides user-space utilities for configuring Linux Ethernet bridges. In practice, it is the legacy brctl-style toolset for creating bridge devices, adding or removing interfaces, and inspecting bridge state. The Linux kernel documentation also notes that modern iproute2 utilities can configure bridge devices, so NiceOS maintainers should verify which interface the distribution expects to keep supporting for this package. (man7.org)

Purpose and typical use cases

This package is used when a system needs Layer 2 bridge management from user space. Typical use cases include:

• turning a Linux host into a software bridge for a VM host, container host, or small network appliance;
• adding physical or virtual interfaces to a bridge for network segmentation or simple transparent forwarding;
• checking bridge membership and basic bridge parameters during administration or troubleshooting. (wiki.linuxfoundation.org)

Typical users are:

• system administrators managing bridge interfaces on servers or appliances;
• developers and integrators who need bridge setup in test environments or automation;
• CI/CD and image-maintenance workflows that validate network configuration tools during builds or integration tests.

Upstream project

The upstream documentation for Linux bridging is maintained by the Linux Foundation networking wiki, and the kernel documentation points to the bridge-utils sources and notes that iproute2 can also be used for bridge configuration. The Linux Foundation page also links to archived bridge-utils releases. NiceOS maintainers should verify upstream expectations before relying on any one tool as the long-term interface. (wiki.linuxfoundation.org)

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM packaging metadata and the spec file;
• SOURCES/ — source-manifest metadata used by the packaging workflow;
• METADATA/ — repository metadata used by the dist-git tooling;
• SBOM/ — software bill of materials data, when present.

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 upstream inputs without embedding the archive payload itself.

Source storage and integrity policy

The repository should stay small and reviewable. Do not add large upstream tarballs or other bulky generated source bundles directly into Git.

For updates, maintainers should verify that:

• the SOURCES/ manifest still matches the intended upstream source set;
• any regenerated packaging metadata is consistent with the upstream source tree;
• no unexpected files were added or removed from the source manifest;
• the license file set and build inputs still match the package intent.

If upstream changes the build system, file layout, or release artifacts, NiceOS maintainers should check whether the manifest and spec need regeneration or manual adjustment.

NiceOS maintenance notes

Before updating this package, please check:

• whether upstream still treats bridge-utils as the desired interface, or whether the distribution should prefer the iproute2 bridge tooling instead;
• whether brctl-related paths, man pages, or build outputs changed upstream;
• whether the package still builds cleanly with the current toolchain and distro macros;
• whether the update changes install paths, permissions, or documentation that downstream consumers may rely on;
• whether any packaging patches, generated files, or repository metadata need refresh.

Main risks to consider:

• upstream functional drift if the package is effectively legacy compared with newer bridge tooling;
• build failures caused by autotools, configure checks, or changed dependencies;
• packaging drift if SOURCES/ is not updated in step with the intended source set.

Build and verification checklist

For RPM maintenance, a practical update checklist is:

1. Verify the upstream source set and compare it with the current SOURCES/ manifest.
2. Review the spec file for changed build flags, install paths, or file lists.
3. Run a clean build in the target NiceOS build environment.
4. Inspect the resulting RPM for expected binaries, man pages, and ownership/permissions.
5. Check that the package metadata and SBOM, if used in this repository, still describe the packaged content accurately.
6. If the package installs configuration files or examples, confirm that upgrades preserve expected behavior.
7. Perform a basic runtime sanity check on a test system, if bridging support is available there.
8. Confirm that the repository remains free of large source archives and that all integrity data stays in SOURCES/.

References

• Linux Foundation networking: bridge
• brctl(8) manual page
• Linux kernel documentation: Ethernet Bridging
• Kernel.org utilities index for net tools

Russian documentation

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

Dist-git repository notes

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