Skip to content

Debian packaging: port downstream packaging improvements - #499

Open
P-EB wants to merge 1 commit into
PowerDNS:masterfrom
P-EB:master
Open

P-EB wants to merge 1 commit into
PowerDNS:masterfrom
P-EB:master

Conversation

@P-EB

@P-EB P-EB commented Sep 25, 2026

Copy link
Copy Markdown
Contributor

As discussed in #462

Scope

This ports the Debian packaging improvements while preserving upstream’s
package names (wforce, wforce-trackalert, and wforce-replfwd), source
package identity, maintainer, and existing build infrastructure.

The changes include:

  • A new wforce-common package for shared files and system account setup.
  • Daemon configuration management through ucf.
  • Debhelper compatibility level 13.
  • Build hardening and libatomic linking on riscv64 and loong64.
  • Installation of the previously omitted wf_dump_entries utility, its
    manpage, and the configuration example.
  • Strict detection of installed files left unpackaged.

Upstream-specific documentation and the historical /etc/wforce.conf
migration are retained.

Two safety adjustments were made when porting the Debian scripts:
temporary configuration files containing credentials are created with
restrictive permissions, and purging the common package only removes
empty shared directories.

As I don't have your build infra, this needs to be heavily tested, and maybe
some bits won't interest you.

Upgrade considerations

Shared-file ownership

/etc/wforce/regexes.yaml moves from wforce to wforce-common, which
also creates the shared system account.

The new packages should be tested as an upgrade from existing upstream
packages, using a strictly higher package version: the transition’s
Breaks and Replaces relationships use << ${binary:Version}.

Configuration management

Existing daemon configurations transition from dpkg-managed conffiles
to ucf. The initial upgrade should be checked for preservation of
administrator changes, credentials, and permissions.

Replication configuration and credentials

The replfwd maintainer script registers the unmodified configuration
template with ucf, then replaces any remaining credential placeholders
in the installed configuration. Generated credentials are therefore
treated as local changes.

An upgrade with an unchanged template preserves existing credentials.
If a changed template is offered and the administrator chooses to
replace the local configuration, credentials will be generated for any
placeholders in the replacement file.

The more elaborate handling in wforce and trackalert preserves
credentials while accommodating their previous configuration-management
behaviour; it is not required for every ucf-managed configuration.

Although the Debian weakforced-replfwd package was introduced with this
approach, upstream already ships wforce-replfwd. Its initial transition
to ucf should therefore be checked with an existing, locally configured
installation. You can mimick what was done for the two other packages, or
I can directly offer a similar version.

If you don't care about the upgrade path but rather just about the result we
can also simplify trackalert and wforce.

Build compatibility

Debhelper compatibility level 13 and strict missing-file detection
should be exercised on the supported Debian and Ubuntu targets.
The latter intentionally fails the build if installed files are left
unpackaged.

Deliberately not ported

  • Debian-specific maintainer information, package naming, changelog,
    Salsa VCS fields, watch, gbp.conf, and the Debian copyright file.
  • Debian’s switch to system LuaJIT, Drogon, and Prometheus libraries,
    and its version-specific Boost dependency. Upstream’s
    wforce-lua-dist and builder-provided libraries remain in use.
  • The bundled Debian regexes.yaml snapshot and the source patch
    replacing its build-time download with a local copy.
  • The source patches adding stdint.h includes and removing Boost
    rpath flags.
  • The replfwd.conf template patch, whose equivalent is already
    present upstream.

Validation status

Shell syntax and the packaging helper steps through binary package
generation were checked using a synthetic installation tree.
This does not constitute a full source build or a successful
upgrade test. As said upwards, some heavy testing is needed. If you
need help please reach out.

The most useful remaining checks are:

  • A build using upstream’s dependency environment.
  • An upgrade from the previous upstream packages with locally modified
    configurations, checking that configurations and credentials are
    preserved.

A standard Debian sbuild environment will need the upstream-specific
dependencies supplied separately.

Preserve upstream package names, maintainer metadata, and build
dependencies while adopting the Debian packaging improvements.

Introduce wforce-common for shared files and account setup, and use ucf
to manage daemon configurations across upgrades.

Adopt debhelper 13, enable hardening and strict missing-file checks, and
install the omitted utility, manpage, and configuration example.

Keep Debian-specific release metadata and source patches out of scope.
@github-actions

github-actions Bot commented Sep 25, 2026 •

Copy link
Copy Markdown

Test Results

  4 files  ±0    4 suites  ±0   45m 32s ⏱️ -13s
 94 tests ±0   94 ✅ ±0  0 💤 ±0  0 ❌ ±0 
210 runs  ±0  210 ✅ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit a5d9d67. ± Comparison against base commit 01d8bbb.

♻️ This comment has been updated with latest results.

@neilcook

Copy link
Copy Markdown
Collaborator

Wow, thanks for this. It will take some time to test and review, so please bear with me.

@simone-leprai

Copy link
Copy Markdown
Collaborator

Hi, first of all thank you for your contribution...

Could you please rebase on master branch and resubmit PR ? debian bulleye building was dismissed and an issue with replfwd.conf was solved in the meanwhile.

So far I was able to build packages for both bookworm and trixie and run some regression tests just fine. There is only one 'issue' with purging (see later)

Tested five scenarios, each in its own fresh container, comparing the new packages against 3.2.0 built from the tag

fresh: new install, reinstall twice, remove (keep configs), install again, purge
upgrade-edited: 3.2.0 with local edits to all configs and regexes.yaml, then upgrade, reinstall twice, purge
upgrade-pristine: 3.2.0 with untouched configs, then upgrade, reinstall twice, purge
upgrade-after-remove: 3.2.0 removed but configs kept, then new packages installed, then purge
upgrade-deleted-conf: 3.2.0 where the admin deleted wforce.conf, then upgrade, then purge

To catch anything left behind, each scenario takes a filesystem snapshot before installing and compares it with one taken after purging. As an extra check, each scenario also starts wforce, trackalert and replfwd the way systemd would: as user wforce, with -s, and they must stay up for a while.

***Works fine

  • Upgrades: all succeed, and dpkg --audit is clean.
  • Local edits: kept in wforce.conf, trackalert.conf, replfwd.conf and regexes.yaml.
  • Credentials: the existing key and web password are kept.
  • Placeholders: none left after install or upgrade.
  • Permissions: configs are tightened from 3.2.0's 644 root to 640 wforce:wforce, and the daemons can still read them as user wforce.
  • Idempotency: reinstalling twice leaves the configs byte-identical, creates no new side files, and shows no prompts.
  • Remove, then install again: remove keeps the configs, and installing again reuses them unchanged.
  • Package handover: regexes.yaml moves to wforce-common cleanly, and every config is registered with ucf.
  • ucf cleanup: purge clears the ucf registry and hashfile.

***Possible issue

  • purge leaves /etc/wforce behind

  • Cause: only wforce-common's postrm runs rmdir /etc/wforce. dpkg purges wforce-common before wforce-replfwd and wforce-trackalert, while their configs are still in the directory. When those two are purged, nothing removes the empty directory. dpkg prints directory '/etc/wforce' not empty so not removed.

  • Also left on upgraded systems: /etc/wforce/.history. It's created by 3.2.0's postinst, which pipes makeKey() into the wforce console. A fresh install of the new packages doesn't create it.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants