On 19/01/17 12:01, Paul Wise wrote:
On Thu, 2017-01-19 at 11:41 +0100, Alec Leamas wrote:
OK, leaving bug open for a day or two in case submitter wants to
re-assign it to dpkg. Will otherwise eventually close it since it
doesn't seem to be a lirc bug.
This is incorrect, it is a lirc bug. When conffiles are renamed,
this must be handled by the package, not by dpkg.
https://packages.debian.org/jessie/amd64/lirc/filelist
https://packages.debian.org/stretch/amd64/lirc/filelist
Feel free to ask the dpkg developers if you don't believe me.
Hey, I'm pretty new in the Debian world. Of course I believe you. I just
try be be clear on how I understand the situation. That's not to say I'm
sure I'm right, but I do get a reply. Thanks for that!
That said, I have absolutely no idea what this means. In particular,
this is nothing like a rename. It's more like retiring hardware.conf
(which was a debian only thing) and replacing it with the upstream
configuration spread over several files. But also keeping some files e.
g., lircd.conf.
The update is a breaking one, requiring manual intervention. I have
tried to handle it to the best of my (limited) abilities.
Also, again, due to a some bad bugs related to how the hardware.conf
file was (mis-)handled, I decided to go for my own system: ship the
upstream files as e. g., lirc_options.conf.dist which is updated but not
used, and create lirc_options.conf if it doesn't exist. In other words,
I don't try to merge possible upstream changes, just to keep the *dist
files around as reference.
So, since this is a bug, have you any pointer/idea how to resolve it?
Cheers!
--alec
