#1029137 Use dh sequencer in debian/rules

Package:
src:rp-pppoe
Source:
src:rp-pppoe
Submitter:
Lee Garrett
Date:
2026-10-09 11:41:02 UTC
Severity:
normal
Tags:
#1029137#5
Date:
2023-01-18 12:44:00 UTC
From:
To:
This bug report is tagged "newcomer" as it a good bug where you can learn about
debian/rules and dh.

debian/rules currently uses a rather lengthy hand-written sequencer for
debhelper tools. Current practice is to use a much shorter one as described at

file:///usr/share/doc/maint-guide/html/dreq.en.html#rules
https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#rules

Where needed, use execute_after_dh_<command>, execute_before_dh_<command>, or
even override_dh_<command> to recreate the original flow as closely as possible.

In the second step you could then trim away any commands that are there for
historical reasons and not needed.

#1029137#10
Date:
2026-10-09 06:03:26 UTC
From:
To:
Attached is a patch modernizing debian/rules to the dh sequencer, as
requested.

Every plain dh_* call that had no custom behavior (dh_installdocs,
dh_installexamples, dh_link, dh_strip, dh_compress, dh_installdeb,
dh_lintian, dh_shlibdeps, dh_gencontrol, dh_md5sums, dh_builddeb) is now
implicit in the dh sequence. What's left as explicit overrides/hooks:

- override_dh_auto_configure / _build / _install: the real source lives
  in src/, not the top level, so default dh_auto_* detection doesn't
  apply -- full overrides, not execute_before/after, since there's no
  default behavior to layer on top of.
- execute_after_dh_auto_clean: additive, removes the extra generated
  files (pppoe.prj, config.h, etc.) the upstream build leaves behind,
  after letting the default dh_auto_clean run first.
- override_dh_installchangelogs: the upstream changelog lives at
  doc/CHANGES, not a path dh_installchangelogs finds on its own.
- execute_after_dh_fixperms: the setuid pppoe binary and the restricted
  dsl-provider file, both applied after the default dh_fixperms run.

That last point surfaced a real, separate, pre-existing bug I want to
be upfront about rather than bury in the diff: in the *original*,
unmodified 4.0-1 rules, the dsl-provider install command ran *before*
dh_fixperms in the sequence -- and dh_fixperms silently resets it back
to default 644/root:root regardless, undoing the intended
`install -m 0640 -o root -g dip`. I reproduced this identically
against a fresh, unmodified 4.0-1 build before concluding it was real
and not something I'd introduced. Since dsl-provider is a PPPoE
connection config file that can hold real ISP credentials,
world-readable was a genuine, if minor, exposure. Fixed by moving the
install into execute_after_dh_fixperms, the one hook guaranteed to run
last -- same fix approach the binary's own setuid bit already needed
for the identical reason.

Also added a lintian-overrides entry for the new non-standard-file-perm
tag this introduces, alongside (not replacing -- I made that mistake
once locally and caught it before generating this patch) the existing
elevated-privileges override already covering the setuid binary.

Verified:
- Full dpkg-buildpackage build succeeds against a fresh pristine 4.0-1
  source tree with this patch applied
- dsl-provider ships 640 root:dip, pppoe ships 4754 root:dip, confirmed
  directly from the built .deb's real contents
- lintian passes clean (0 warnings) with both overrides in place
- Patch applies with zero errors against a fresh pristine extraction,
  confirmed on a second, independent apply+build+verify pass

Changes:
- debian/rules (modernized to dh sequencer)
- debian/changelog
- debian/pppoe.lintian-overrides (new tag added, existing one preserved)

#1029137#17
Date:
2026-10-09 11:32:54 UTC
From:
To:
Hi Stefan (and Claude?),

the purpose of this bug is for newcomers interested in Debian packaging to have
a practical example to work on with a real life benefit. Handing the issue to a
LLM defeats the purpose here as there is no learning experience for you, and
Claude is not a newcomer.

While the code itself is mostly correct, the output is overly verbose. Typical
for LLM output, every code line is accompanied by 5+ lines of comments. The
changelog for example should rarely exceed a single line per point. Mentioning
existing code that was not changed does simply not make sense there.

Few questions:
Are you currently using the package or how did you find this bug report?
You removed:
DPKG_EXPORT_BUILDFLAGS = 1
include /usr/share/dpkg/buildflags.mk
Can you justify that change?

Regards,
Lee