Hi On Tuesday 17 January 2012, Holger Levsen wrote: > Package: lirc > Version: 0.9.0~pre1-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package failed the piuparts > upgrade > test because dpkg detected a conffile as being modified and then prompted the > user for an action. As there is no user input, this fails. But this is not > the real problem, the real problem is that this prompt shows up in the first > place, as there was nobody modifying this conffile at all, the package has > just been installed and upgraded... > > This is a violation of policy 10.7.3, see > http://www.debian.org/doc/debian-policy/ch-files.html#s10.7.3, which > says "[These scripts handling conffiles] must not ask unnecessary questions > (particularly during upgrades), and must otherwise be good citizens." > > http://wiki.debian.org/DpkgConffileHandling should help with figuring out how > to do this properly. > > In http://lists.debian.org/debian-devel/2009/08/msg00675.html and followups > it > has been agreed that these bugs are to be filed with severity serious. […]
Thanks for the notice, while I don't exactly share that severity
classification (although that is of course covered by the policy text),
I'll work on this as soon as possible.
Due to historically problematic config handling and several upstream
changes requiring further adaptions to initscript and config, it will
require slightly larger and more invasive changes than I would have
been comfortable with for wheezy. Especially given that the kernel
modules were finally merged mainline, but partly changed module names
and/ or behaviour (switching to the new RC_CORE kernel subsystem).
Actual users of several classic lirc modules (mceusb/ mceusb2, i2c,
etc.) will have to do manual config changes (hardware.conf and
lircd.conf key mappings, mostly not prompted for by debconf) as part of
the wheezy upgrade - only few of these changes can be migrated
automatically - for others nothing will change…
But I will make sure that at least upgrades for unconfigured/ default
lirc(d) installations won't trigger the conffile dialogues anymore.
Basic plan:
- dissolve /etc/lirc/hardware.conf and (semi-automatically) migrate
relevant parts of its knowledge to /etc/default/lirc, using a
slightly different configuration syntax (this is a topic on lirc
upstream's whishlist for distro packaging anyways).
- deprecate, but support for wheezy(?), (kernel-) module loading
through /etc/lirc/hardware.conf and warn about it. Modern devices are
autoprobed by udev, old-style ones (bt829, serial, sir, parallel,
zilog) are recommended to be loaded by the local administrator
(manual addition to /etc/modules).
- properly deal with new style devices supporting both the old lirc
protocol and different protocols of the new RC_CORE subsystem (like
RC-5/ RC-6/ NEC/ jvc/ sony/ mce_kbd/ other and lirc, eventually
resulting in key events detected twice).
However these changes will require very careful upgrade- and regression
testing on several hardware classes (kernel old-style, kernel
new-style, kernel new-style with multiple supported protocols,
userspace driver) and might take a little longer than I'm personally
comfortable with for an RC bug.
Regards
Stefan Lippers-Hollmann
signature.asc
Description: This is a digitally signed message part.
