bgpq4

Overview

bgpq4 is a BGP filter generation tool. It turns IRR data into router-policy outputs such as prefix-lists, access-lists, policy-statement terms, and as-path lists. In a Linux distribution, this package exists so administrators can install a maintained build of the upstream tool without rebuilding it from source every time. (github.com)

Purpose and typical use cases

Typical use cases include:

• generating routing filters from IRR objects before applying them on routers;
• keeping prefix filters compact and reproducible from the same source data;
• producing output for different vendor or configuration formats supported by the upstream tool;
• integrating filter generation into network automation and configuration pipelines. (github.com)

Typical users are network administrators, routing engineers, and CI/CD maintainers who manage router policy generation. Security teams may also use it when they need to review or automate routing-policy data, but NiceOS maintainers should verify any security-related workflow against local policy before relying on it.

Upstream project

The upstream project is bgp/bgpq4 on GitHub. Its own documentation describes it as a BGP filter generator, and the project uses autotools for building from the source tree. The upstream repository also includes a test suite and reference outputs. (github.com)

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic;
• SOURCES/ — source manifests and other packaging metadata;
• METADATA/ — dist-git metadata used by the packaging workflow;
• SBOM/ — software bill of materials material, when provided by the packaging workflow.

Large upstream source archives are intentionally not stored in this Git repository. Instead, source integrity is tracked through manifest files in SOURCES/. This keeps the repository smaller and makes updates easier to review.

Source storage and integrity policy

The source policy for this package is to keep the Git repository focused on packaging metadata rather than vendored upstream archives. The SOURCES/ manifests identify what should be fetched for the build, while the actual large archives stay outside the repository. NiceOS maintainers should verify that the manifests still point at the expected upstream source and that any packaging metadata was updated consistently.

Before updating the package, check:

• whether upstream build files, generated files, or test data changed;
• whether SPECS/ needs spec updates for new build requirements or install paths;
• whether SOURCES/ needs regeneration because the upstream source tree changed;
• whether SBOM/ or other packaging metadata needs refresh;
• whether the update changes output formatting or test expectations.

NiceOS maintenance notes

Recommended review points for maintainers:

• compare the upstream changelog and release notes with the current packaging assumptions;
• verify that the package still builds cleanly with the distribution toolchain;
• run the upstream tests or the package-level checks that are available in the build environment;
• inspect any generated files that may have changed in the upstream source tree;
• confirm that the packaged files still match the intended upstream install layout;
• review whether policy-generation behavior changed in a way that could affect existing automation.

If upstream regenerates autotools artifacts or reference outputs, maintainers should verify whether those files are meant to be shipped from source or recreated during the build. Do not assume generated files are stable across all upstream updates.

Build and verification checklist

For RPM maintenance, a practical checklist is:

1. Refresh the source metadata in SOURCES/ if the upstream source set changed.
2. Review the spec file for build-system or dependency changes.
3. Build the SRPM and binary RPMs in a clean environment.
4. Run the package test suite if it is enabled for the build.
5. Confirm that the installed files and man pages match expectations.
6. Check the resulting package for missing files, unwanted files, and packaging warnings.
7. Verify that any generated reference data still matches the upstream behavior.
8. Re-check licensing and included notices if upstream packaging files changed.

References

• bgpq4 upstream repository
• bgpq4 manual page in the upstream repository

Russian documentation

See README_RU.md.

Dist-git repository notes

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