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