[Pkg-lirc-maint] Bug#655969: lirc: prompting due to modified conffiles which where not modified by the user

[Stefan Lippers-Hollmann]

Hi

On Friday 08 March 2013, Thomas Preud'homme wrote:
> Le vendredi 8 mars 2013 03:32:29, Stefan Lippers-Hollmann a écrit :
[…]
> > On Thursday 07 March 2013, Thomas Preud'homme wrote:
[…]
> > Thanks for looking into this bug, the patch itself is correct and will
> > avoid the reported piuparts upgrade issue (which is technically RC), so
> > please feel free to upload the NMU (I'd appreciate it).
> 
> Great, I've been suggested to add a test for the version being upgraded from 
> and testing if the file exist. Once done, I'll upload it (should be today or 
> sunday).

ack, thanks a lot.

> > Just be aware that it only papers over a larger issue that forces
> > most lircd users actually driving various lirc hardware to reconfigure
> > their config file regardless of this change; please see
> > 	http://anonscm.debian.org/viewvc/pkg-
> lirc/lirc/trunk/debian/NEWS?view=mark
> > up or
> > 	https://lists.debian.org/debian-backports/2012/04/msg00076.html
> > for background information.
> 
> Ack, the patch is not as useful as it could be. Can't lirc be installed by a 
> Recommends dependency? If yes, it might be that the package is not of interest 
> of the user and this message would thus annoy him/her. If lirc is on the 
> contrary always installed when the user intend to use it, then the best 
> approach is probably to tag it wheezy-ignore. It would be an even smaller 
> change than this patch.

[detailed analysis below, feel free to skip this list]
The rdepends of lirc, excluding packages built from the lirc source 
package itself, are:
- vdr			Video Disk Recorder for DVB cards
  Recommends: lirc, ttf-bitstream-vera | ttf-freefont
  vdr has three different ways of navigation (channel selection, lirc 
  is probably the most important one which always works (provided you 
  have properly configured hardware), keyboard based navigation is only
  possible through selected frontends (e.g. xineliboutput-sxfe, only 
  this special frontend can transport key presses to the vdr dæmon) or 
  web based, through e.g vdr-plugin-live.
  This makes it, while not mandatory, rather likely that a vdr user 
  also uses lirc hardware; it's probably a wishlist bug that vdr 
  doesn't have an alternative recommends on inputlirc (an alternative 
  lircd implementation)
- inputlirc	Zeroconf LIRC daemon using input event devices
  Suggests: lirc, input-utils
  not pulled in automatically, the suggests looks weird at a first 
  glance (as inputlirc can provide a full lircd replacement for a 
  subset (only event based-) devices also supported by lircd, but the
  reasons for this are the supporting tools of the lirc package (mostly
  irw, to generate button <--> keycode mappings, eventually irexec).
  Technically speaking, it might make sense to split out these tools
  out of the lirc package, but that would leave lircd/ lircmd in a tiny
  package of their own - something ftp-master doesn't exactly prefer.
- kremotecontrol	frontend for using remote controls
  Recommends: lirc
  This one is a tough call, isolated to kremotecontrol, the Recommends
  is correct, but kremotecontrol is a hard dependency of kdeutils (meta
  package, probably installed for most KDE users), which in turn is a
  hard dependency of kde-full…
  Besides the typical lirc | inputlirc suggestion, this may be a larger
  cause for lirc installations even if the user actually has not need 
  for it; it's also a relatively new dependency, as its KDE3 
  predecessor -kdelirc- was not part of kdeutils at the time.
  Technically the dependency chain is totally correct and weakening it
  wouldn't be a logical conclusion for these meta packages, but given 
  the "lirc is only useful, if you have special, non-standard hardware"
  (an IR receiver and a remote to use it) a suggests might be more in 
  order.
  kremotecontrol didn't exist in squeeze, only its predecessor kdelirc,
  which was a seperate source package and not part of kdeutils; it was
  only suggested by kdetv, no hard dependencies or recommends.
- freevo-lirc		home theater framework - LIRC support
  Depends: freevo (= 1.9.2b2-4.2), python-pylirc, lirc
  This one seems to be fine, no rdepends - not even a suggestion from
  any other package.
  (disclaimer, I've never used freevo)
- enna			a powerful MediaCenter application based on EFL
  Suggests: lirc
  only a suggests, so no issue here.
  (disclaimer, I've never used enna)
- banshee-extension-lirc	LIRC integration extension for Banshee
  Depends: banshee-extensions-common (= 2.4.0-1), lirc, libc6 (>= 2.2.5), liblircclient0, libmono-corlib4.0-cil (>= 2.10.1)
  A recommends of banshee-community-extensions, a meta package, which 
  in turn has no rdepends, this may be slightly inflate the number of
  unneeded lirc installations, but I'm not sure of how commonly this
  meta package is in the banchee community - probably the same Depends
  vs Suggests considerations as for kdeutils above apply.
  (disclaimer, I've never used banshee)

So the only source of automatically pulled in, but unneeded, lirc 
installations is kde-full depending on kdeutils, depending on 
kremotecontrol, which finally recommends lirc - this one worries me a
bit (probably worth contacting the KDE maintainers post wheezy).

> > For these reasons, I probably would have asked for a wheezy-ignore, in
> > order to get a complete fix into jessie, rather than only fixing the
> > reported bug. However your proposed nmudiff won't interfere with those
> > for-jessie changes and I'd appreciate if you could upload it.
> 
> If lirc is always installed to be used (never pulled by a Recommends), then 
> tag it wheezy-ignore is probably the best approach indeed.
[…]

Pulling in the lirc (or inputlirc for that matter) package, which means
the dæmon, without a strong indication that the user actually owns IR 
receivers/ transceivers and wants to use them is most likely a bug. 
lirc (or inputlirc) cannot do anything useful, unless properly 
configured, which means at least selecting the driver type (out of ~60 
options - userspace and staging drivers, most of them can't be 
autoprobed), specifying the device node it should listen on (in many 
cases a custom udev rule is also needed, to get a stable event device 
symlink) and the remote button <--> key event mapping is required. None
of these can be detected automatically, as you can pair pretty much any
IR remote with 'better' (multi-protocol) IR receivers, only few are 
semi-locked to the specific remote they were shipped with).
While probably defendable for vdr (it's hard to control without an IR 
remote, but still technically possible), it's a bit too strong for the 
kde-full --> kdeutils --> kremotecontrol dependency chain (but totally 
fine for kremotecontrol itself).

Fortunately, for the sake of the piuparts aspect of this bug, 
kderemotecontrol is a new package in wheezy, which means neither 
squeeze --> wheezy dist-upgraders (who had kdeutils installed) nor 
new wheezy installations would be faced with the conffile prompt (but
a most likely 'useless' lirc installation, due to the new dependencies,
of course). The next post-wheezy lirc upload will fix this anyways (but
the proper solution is just far too extensive for wheezy), this part of 
the config overhaul is already present and fully functional in the 
packaging Vcs, only the automagical parts (and better documentation) 
are still in progress.

Regards
	Stefan Lippers-Hollmann
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-lirc-maint/attachments/20130308/c95f65ad/attachment.pgp>