On Thu, 2017-12-07 at 16:41 +0100, Felix Zielcke wrote: > Is the version number the problem or what else could it be?
I think so; based on what the manual page says (quoted below), when you
initially added the removal in 1:3.6.25-6, you should have set the
prior-version to 1:3.6.25-6~ instead of 1:3.6.25-5~. I think to fix the
problem next time you make an upload "X", change prior-version to "X~".
Defines the latest version of the package whose upgrade should
trigger the operation. It is important to calculate prior-version
correctly so that the operations are correctly performed even if the
user rebuilt the package with a local version. If prior-version is
empty or omitted, then the operation is tried on every upgrade
(note: it's safer to give the version and have the operation tried
only once).
If the conffile has not been shipped for several versions, and you
are now modifying the maintainer scripts to clean up the obsolete
file, prior-version should be based on the version of the package
that you are now preparing, not the first version of the package
that lacked the conffile. This applies to all other actions in the
same way.
For example, for a conffile removed in version 2.0-1 of a package,
prior-version should be set to 2.0-1~. This will cause the conffile
to be removed even if the user rebuilt the previous version 1.0-1 as
1.0-1local1. Or a package switching a path from a symlink (shipped
in version 1.0-1) to a directory (shipped in version 2.0-1), but
only performing the actual switch in the maintainer scripts in
version 3.0-1, should set prior-version to 3.0-1~.
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
