Deleting debian/changelog turns the changelog gate green #15

New issue

Open

opened 2026-09-28 06:53:37 -03:00 by marcos-mendez · 0 comments

marcos-mendez commented

2026-09-28 06:53:37 -03:00

(Migrated from github.com)

bin/require-changelog returns 0 when debian/changelog does not exist. So
deleting the changelog in a pull request turns package / changelog green.

Fifteen repositories in the organization call this gate. In every one of them,
the cheapest way past it is to remove the file it exists to check.

Measured while auditing the gate's reach for Keel-Linux/fab#9. The same
behaviour is why five repositories that carry debian/control and
debian/rules but no committed debian/changelog cannot simply be wired up:
the check would be permanently green and assert nothing. But that is the
symptom. The cause is that absence is treated as success.

Note that dpkg-buildpackage cannot run without a changelog, so "a package
source with no changelog" is not a state that can legitimately ship. Absence is
always a defect in a repository that builds a package, never an exemption.

What closes this

The gate refuses when a repository that ships a package has no
debian/changelog, rather than passing.
Deciding how it knows a repository ships a package: debian/control and
debian/rules both present is the obvious test, and the five repositories
above all satisfy it.
A test for the deletion case specifically, because that is the bypass and it
is the one thing the current suite does not cover.
Once it refuses, the five repositories can be wired up and will go red
honestly, which is the point.

Order

This lands before the five are wired up, not after, or they get a green check
that asserts nothing and someone learns to trust it.

There are other changes in flight against this repository (#12 the boot gate,
#14 the negation guard). Check for conflicts in the shared workflow files
before starting, and say in the pull request which of the three should land
first.

Org-wide context on which repositories call the gate: Keel-Linux/tracker#18.

`bin/require-changelog` returns 0 when `debian/changelog` does not exist. So **deleting the changelog in a pull request turns `package / changelog` green.** Fifteen repositories in the organization call this gate. In every one of them, the cheapest way past it is to remove the file it exists to check. Measured while auditing the gate's reach for `Keel-Linux/fab#9`. The same behaviour is why five repositories that carry `debian/control` and `debian/rules` but no committed `debian/changelog` cannot simply be wired up: the check would be permanently green and assert nothing. But that is the symptom. The cause is that absence is treated as success. Note that `dpkg-buildpackage` cannot run without a changelog, so "a package source with no changelog" is not a state that can legitimately ship. Absence is always a defect in a repository that builds a package, never an exemption. ## What closes this - The gate refuses when a repository that ships a package has no `debian/changelog`, rather than passing. - Deciding how it knows a repository ships a package: `debian/control` and `debian/rules` both present is the obvious test, and the five repositories above all satisfy it. - A test for the deletion case specifically, because that is the bypass and it is the one thing the current suite does not cover. - Once it refuses, the five repositories can be wired up and will go red honestly, which is the point. ## Order This lands before the five are wired up, not after, or they get a green check that asserts nothing and someone learns to trust it. There are other changes in flight against this repository (`#12` the boot gate, `#14` the negation guard). Check for conflicts in the shared workflow files before starting, and say in the pull request which of the three should land first. Org-wide context on which repositories call the gate: Keel-Linux/tracker#18.