On 10/31/24 17:44, Lorenzo Puliti via Piuparts-devel wrote:
Package: piuparts
Version: 1.4.4
Severity: normal
X-Debbugs-Cc: plore...@disroot.org
Dear piuparts maintainer,
I'm going to use dpkg-divert on essential files with one of my
package (runit-init); since files to be diverted are shipped by an
essential package, I'm using '--no-rename' option.
When the package is tested, piuparts ERROR with
debsums: missing file /usr/sbin/invoke-rc.d.real (from init-system-helpers
package)
debsums: missing file /usr/sbin/service.real (from init-system-helpers
package)
debsums: missing file /usr/share/man/man8/invoke-rc.d.8.gz.real (from
init-system-helpers package)
debsums: missing file /usr/share/man/man8/service.8.gz.real (from
init-system-helpers package)
after runit-init (the package that adds the diversion) is removed, piuparts
detects that,
for example, /usr/sbin/invoke-rc.d.real should be there (but it's missing) when
in fact is /usr/sbin/invoke-rc.d that should be there (and it's not missing).
It's not piuparts detecting the error but debsums, piuparts just
propagates it.
I believe my package does it the right way, when it's removed it removes the
diversion and it
makes sure that diverted files are restored in their original location.
I don't think so.
The copying bits in the prerm belong to the preinst (when the "other"
variant is still there), otherwise you copy (and restore) the "runit"
variant.
Can you reproduce this manually in a minimal chroot with debsums
installed where you install init-system-helpers, install runit-init,
remove runit-init?
And frequently check with debsums -ac --ignore-obsolete
Andreas
