[Pkg-lirc-maint] Bug#513769: Bug#513769: dpkg-reconfigure lirc always fails

Sun Feb 1 22:18:02 UTC 2009

Hi

On Sonntag, 1. Februar 2009, The Eclectic One wrote:
> Package: lirc
> Version: 0.8.3-3
> Severity: grave
> Justification: renders package unusable
> 
> # dpkg-reconfigure lirc
> Stopping lirc daemon: irexec lircmd lircd.
> .udevdb or .udev presence implies active udev.  Aborting MAKEDEV invocation.
> ##################################################
> ## LIRC IS NOT CONFIGURED                       ##
> ##                                              ##
> ## read /usr/share/doc/lirc/html/configure.html ##
> ##################################################
> Additional hint: Either /etc/lirc/lircd.conf or
>  /etc/lirc/hardware.conf doesn't exist or either
>  of the two has the string UNCONFIGURED in it at
>  some important place. Try: 'dpkg-reconfigure lirc'
> Starting lirc daemon:.
> 
> But lircd is never started.  Trying the same command again results in
> the same messages and lirc is still not configured.  In fact,
> /etc/lirc/lircd.conf begins with #UNCONFIGURED (both files
> referenced in the error message above exist).  It seems counter-intuitive
> that configuring the package doesn't actually do it.  Shouldn't the
> dpkg-reconfigure scripts do what lirc needs to work properly, and
> mark it as configured (ie: removing the #UNCONFIGURED line)?
> 
> This is on a new Lenny installation on a blank disk, so there are no
> leftovers from previous versions.  I'll do whatever testing is
> required if the problem can't be isolated.  Just let me know.

Just to explain what Samuel Thibault has already mentioned, it is 100% 
impossible to do all steps required to set up lirc using debconf.

On the one hand there are 16 (17 in lirc 0.8.4, even more with non upstream
patches) kernel modules and 38 userspace drivers available, some of them
could be autodetected (USB based ones and those who appear on the PCI bus),
a lot cannot be detected at all (serial, parallel, gpio, sir). Some need
special configuration (IRQ and memory address for serial, sir and parallel,
path to an input device for devinput devices), making all of this 
selectable simply isn't a task for debconf and doing so would be worth a
higher priority bug (debconf abuse) on its own. But even not looking at the
receiver hardware itself (hardware.conf), automatically creating or 
allowing to select a matching lircd.conf is even more impossible, as you 
can mate (withing the limits of matching IR frequency between receiver and 
remote, but with broad overlaps in typical consumer devices) any IR 
receiver with any IR remote, not only the one shipped with your receiver,
but just about any; shipped with lirc 0.8.3 are 61 templates for well known
remotes at this moment, but nothing against repurposing you old VCR remote
for lirc and mating it with a lirc_serial or lirc_atiusb or even a lirc_sir
transceiver. Not even starting to talk about configuring several remotes 
with one receiver or even more than one receiver...
If you'd find any solutiong to this, it won't be debconf by design 
("debconf is not a registry").

So yes, you're in control and will have to open a text editor and start 
editing hardware.conf and either select, download or create (irrecord) a
lircd.conf for your particular remote, lirc's initscript even tells you
where to look for these config files, which do - in general, at least for 
the devices I know about - work and are rather well commented/ documented.
Therefore I have a hard time understanding how this would "render[s] 
package unusable".

That said, yes the debconf usage in lirc is questionable and in desperate 
needs of getting revised, actually a number of debconf questions are never 
asked anymore, because they're totally obsolete "Create LIRC device nodes 
if they are not there?", c'mon, that's udev's job (with a fallback to 
MAKEDEV for systems not using udev) or "Old configuration files found", 
pre-sarge (and I'm actually too lazy to find out when exactly this was 
added), "Delete /var/log/lircd?" (lirc logs to syslog for more than 2 
releases already, again I'm too lazy to determine the actual date this 
changed), ... So while there is lots of stale information in lirc's debconf
usage, none of these ever allowed configuring a device through lirc - I 
explained why this isn't possible in the first paragraph. Therefore
reconfiguring lirc doesn't fail at all, postinst and debconf scripts 
execute perfectly fine - just (re-)starting /etc/init.d/lirc cannot succeed
without a proper configuration, which is exactly what it prints to stdout/ 
stderr.

Why hasn't this been cleaned up yet? Well, the answer to this is easy, 
there were much more important (real RC severity) fixes required before
thinking about cosmetics, furthermore you don't start to redesign debconf
templates 2-3 months before a freeze (or during a deep freeze, like now), 
at least not if there is no pressing need. The fact that the historic 
debconf usage doesn't adhere to established policy and packaging standards
doesn't make this easier without breaking existing setups easier.

Looking into the immediate future, there is lirc 0.8.4+ (which got released
while lenny was already frozen and therefore didn't qualify for a freeze 
excemption) which does bring initial hal support for new fashioned 
receivers (those which can be found by udev) and will allow semi-automatic
configuration for their hardware (not lircd.conf and neither for legacy
receivers as lirc_serial, lirc_parallel, lirc_sir, lirc_gpio, etc.) and 
which enforces larger debconf (and packaging) changes.

That said, following the exact wording of this bugreport, there isn't any
bug at all, as you will "never" be able to configure lirc solely through 
debconf. But of course, the debconf usage within the lirc packaging needs
a thourough clean up, which will actually result in a serious reduction 
(debconf is totally useless for lirc-modules-source, as there is a sane 
configuration for all (desktop) systems by compiling all kernel modules 
(embedded like systems can still influence the modules to be build through 
lirc-modules-source.conf), IRQ and port setting cann and should be done at 
module load time through modprobe.d) of debconf questions, not in 
extending (or "fixing") them.

Regards
	Stefan Lippers-Hollmann
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.alioth.debian.org/pipermail/pkg-lirc-maint/attachments/20090201/1f795dea/attachment.pgp 