Hi,

This is severity wishlist, just close it if you don't like it.

It seems that your pkgos_postrm and mine dh_cruft are
doing mostly much of the same thing: generating .postrm snippets
with extra team-specific heuristics.

dh-cruft is use for all the games of the Games Team who need it.

pkgos_postrm the same for OpenStack.


I'm not asking you to make all your packages rely on some other guy debhelper script.

What I'm asking is wether you would consider generating the
/usr/share/cruft/rules/<package> files that register the dynamic files
unknown to dpkg ? These are needed by the cruft-ng analysis tool.


This is what the original proposal call "extrafiles":
https://lists.debian.org/debian-policy/1998/04/msg00089.html

I'm finally aiming for a version 1.00 of cruft-ng analysis software.
Fixing all the packages of OpenStack at once with little effort would be awesome.


So each /usr/share/cruft/rules/${PKPRM_TEMPLATE_PREFIX} would contains:
 /var/lib/${PKPRM_TEMPLATE_PREFIX}/
 /var/log/${PKPRM_TEMPLATE_PREFIX}/

/var/lock is on a tmpfs an as such out of scope.


Greetings


Alexandre
------

https://sources.debian.org/src/cruft-ng/0.9.84/dh-cruft/dh_cruft

		if ($var_games) {
			push @purgelines, "    if test -d \${DPKG_ROOT:-}/var/games/";
			push @purgelines, "    then";
			push @purgelines, "        rmdir --ignore-fail-on-non-empty \${DPKG_ROOT:-}/var/games/";
			push @purgelines, "    fi";

		}
		autoscript($package, "postrm", "postrm-cruft", { 'PURGE' => join("\n", @purgelines)});

-------------

$ cat pkgos_postrm
#!/bin/sh
# -*- mode: shell-script -*-

# Perform cleanups when removing a package
# Prototype: pkgos_postrm <template-prefix-name> <package-name> $@
# Example:   pkgos_postrm neutron                neutron-common $@
pkgos_dbc_postrm () {
        local PKPRM_TEMPLATE_PREFIX PKPRM_PACKAGE_NAME

        PKPRM_TEMPLATE_PREFIX=${1}
        PKPRM_PACKAGE_NAME=${2}
        shift
        shift

        if [ -f /usr/share/debconf/confmodule ] ; then
                . /usr/share/debconf/confmodule
                # If the package has the template, then it means we're having a db,
                # and therefore we can call the dbconfig-common clean function.
                db_get ${PKPRM_TEMPLATE_PREFIX}/configure_db
                if [ "$RET" = "true" ] ; then
                        if [ -f /usr/share/dbconfig-common/dpkg/postrm ] ; then
                                . /usr/share/dbconfig-common/dpkg/postrm
                                dbc_go ${PKPRM_PACKAGE_NAME} $@
                        else
                                rm -f /etc/dbconfig-common/${PKPRM_PACKAGE_NAME}.conf
                                if which ucf >/dev/null 2>&1; then
                                        ucf --purge /etc/dbconfig-common/${PKPRM_PACKAGE_NAME}.conf
                                        ucfr --purge ${PKPRM_PACKAGE_NAME} /etc/dbconfig-common/${PKPRM_PACKAGE_NAME}.conf
                                fi
                        fi
                fi
        fi

        rm -rf /var/lib/${PKPRM_TEMPLATE_PREFIX} /var/log/${PKPRM_TEMPLATE_PREFIX} /var/lock/${PKPRM_TEMPLATE_PREFIX}
}

Hi Alexander,

Thanks for your bug report, however, I'm not sure what action you're
calling for. Are you asking that I get rid of pkgos_postrm and use
"yours" as a replacement?

Cheers,

Thomas Goirand (zigo)

"yours" as a replacement?


No, absolutely not.

I'm asking merely asking that pkgos_postrm, or the framework that insert it
in the build also speak the same simplistic "wire protocol" as dh_cruft:
that means writing in the resulting .deb a compliant
/usr/share/cruft/<package> listing /var/lib<package-or-something>/ as
volatile files not known to dpkg. The purge action is already correctly
handled as required by Policy.

It is a similar situation as this: I have a big python machinery that does
RPC using python3-pika and marshalling of requests using python
annotations. There's a reference python annotation. My DotNet colleague
will just talk to RabbitMQ without using my Python library, just using the
correct wire protocol.

You can have a look at snake4, it is a tiny game that uses dh-cruft and
build in a few seconds.

I know it somewhat not easy to "sell" this idea at large, I m only asking
here because I feel that 5 lines of code somewhere will fix this at once
for all OpenStack packages then you ll never have to think about it again.

Greetings

Alexandre



Le mar. 19 mai 2026, 08:44, Thomas Goirand <zigo@debian.org> a écrit :

Hi Alexandre,
I'm always happy to receive good advice, especially from someone like
you who has helped me to make a lot of improvement on the OpenStack
packages thanks to so many bug reports.

I had a look into snake4 as you suggested, and the only thing I could
see is dh-sequence-cruft as build-depends, and snake4.purge containing
/var/games/snake4.score. If I understand well, what it's doing is writing:

/usr/share/cruft/rules/<package>

which contains a list of folders owned by "my" package once it's removed
but not purged. Am I correct?

So if I understand correctly, I'd only have to add something like:

echo "/var/lib/<package>/**
/var/lib/<package>" >/usr/share/cruft/rules/<package>

in my postrm scripts?

Please let me know if I understood correctly.

Cheers,

Thomas Goirand (zigo)

Hi again,

I digged deeper (
https://codesearch.debian.net/search?q=pkgos_dbc_postrm&literal=1 )
and I know realise that pkgos_dbc_postrm work at the same level as,
for example "deb-systemd-helper" that got injected in so many postinst scripts;
and not at the same level as dh-cruft that changes how maintainers
scripts get templated.

So my original idea won't work.

Would you be ok for 15 merge requests on Salsa that translates a bit
of postrm.in
into a debian/purge file + adding dh-sequence-cruft build dependency ?

This won't hurt back portability, helper was basically done in 2022 already.



codesearch 'pkgos_dbc_postrm path:postrm.in' --only-package | wc -l
15

Greetings

Alexandre


Le jeu. 21 mai 2026 à 14:03, Thomas Goirand <zigo@debian.org> a écrit :