An "update-package" command, run at install time by the maintainer's
scripts right after file generation succeeds, would head off potential
problems with synchronization that are outside of the Maintainer's
control (e.g., DEBIAN/dynfiles containing incorrectly generated paths)
and would be simpler to implement, specifically, dynfiles
vs. "update-package":

Having recently come from a Solaris background (migraiting to Debian),
if I understand what you're saying here, then this is the way Sun
handled the problem. In their version of debian/postinst you would call
a command and pass it the path of the file you just created, along with
any extra necessary information needed to add an entry to the packaging
database.
As an example:
echo "Creating /etc/foo.cfg..."
cat > /etc/foo.cfg << EOF
...stuff...
EOF
dpkg-install-file <package-name> /etc/foo.cfg
After that, when doing the Sun version of a purge, you had a choice:
A) Remove the file yourself, and call a second command that would remove
it's database entry, or
B) Ignore it and let the package manager remove both the file and it's
database entry for you, since it now knows of the file's existence and
it's affiliation with your package.
Having this background writing Solaris packages, and a desire to 'do it
right' as I learn Debian, is what prompted me to ask in the first
place. It just seems a little cleaner: you could query dpkg for what
package *every* file came from -- no files left out; and you don't
necessarily have to rely on the package maintainer to remember to clean
up after themselves during a purge, so long as they registered their
dynamically-created files right after creation.
Anyway, that answered my question -- Debian doesn't worry about
dynamically-created files.
L8r,
Michael Peek