As I understand it, this is what happened:
src:pbuilder builds two binary packages: pbuilder and pbuilder-uml.
pbuilder-uml depends on pbuilder.
pbuilder suggests pbuilder-uml.
pbuilder-uml ships /etc/pbuilder/pbuilder-uml.conf.
pbuilder is of course not supposed to ship the same conffile.
Because of a latent bug in debian/rules, pbuilder_0.217 shipped multiple
files that belonged to pbuilder-uml, including
/etc/pbuilder/pbuilder-uml.conf. This is bug #800416, which was promptly
fixed in pbuilder_0.218. The faulty package was only in unstable for
about a day.
However, people who had the buggy package installed now have an obsolete
conffile on their disks.
[If all the above had been written in the initial mail, and I hadn't had
to dig through bugs.d.o and snapshot.d.o, I would have been so happy!]
* Mattia Rizzolo <mat...@mapreri.org>, 2015-10-10, 16:30:
That file is supposed to be only on pbuilder-uml binary, so I can't
just use rm_conffiles to remove it in pbuilder, as that would blindly
remove it while pbuilder-uml might be using it.
dpkg-maintscript-helper has some ownership checks implemented, but I'm
afraid they might be insufficient.
It might be tempting to call d-m-h conditionally, only if pbuilder-uml
is not installed, but it might be difficult to get it right in all
corner cases. (Keep in mind that you call d-m-h multiple times, and the
status of pbuilder-uml can change between the calls.)
I'd suggest to do something very simple instead:
In pbuilder's postinst, if pbuilder-uml status is not-installed, simply
rm -f /etc/pbuilder/pbuilder-uml.conf.
(Note that dpkg will notice that the conffile is gone only on the
NEXT pbuilder upgrade. I don't think this is a big deal, given that the
bug affected only unstable users, who will most likely upgrade pbuilder
many times in the near future anyway.)
Another possibility is to refrain from fixing the bug, and let unlucky
users clean their systems themselves.
--
Jakub Wilk
