libgssapi-krb5-2 does not properly clean up the obsolete 'conffile'
/etc/gss/mech.d/README on upgrades. The file was shipped in stretch
but is not removed on upgrades to buster (or later to bullseye).

This breaks piuparts tests of the upgrade path oldstable -> stable ->
testing because libgssapi-krb5-2 is part of the base system in bullseye
and depending on whether libgssapi-krb5-2 was pulled in as dependency
in stretch, piuparts will complain about the state of
/etc/gss/mech.d/README

While I could work around this ... I'd prefer to see this fixed properly
in bullseye, please apply the attached patch.

Andreas

control: tags -1 wontfix

This is a duplicate of a wontfix bug.
Don't have time to go look up the other bug now.

control: tags -1 wontfix

This is a duplicate of a wontfix bug.
Don't have time to go look up the other bug now.

The other bug is 910344, which in turn refers to #868121.

But TBH, I don't quite understand why this should be a wontfix.


- The file seems to be a plain README file with no further
functionality so is there any good reason for leaving over that
obsolete stuff?
New installations don't get it either - and still work just fine.


- As mentioned in #868121 the policy says:
https://www.debian.org/doc/debian-policy/ch-files.html#s10.7.3
"Obsolete configuration files without local changes should be removed
by the package during upgrade."

Benjamin's point that this wouldn't be a conffile
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868121#25) is not
really valid, IMO:

it's registered in dpkg as a conffile => it's a conffile => it's
configuration



I mean you could still leave it in place if it would actually have user
modifications, but even then it should be unregistered as a conffile
with by using dpkg-maintscript-helper(1).

(AFAIU, the version that needs to be specified for that is NOT
the version where the conffile was dropped, but rather "the
latest version of the package whose upgrade should trigger
the operation"

Quoting the manpage:
           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~.


Cheers,
Chris.