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

Fri Mar 8 17:01:55 UTC 2013

[Note to RT: this is about adding a wheezy-ignore tag for #655969]

Le vendredi 8 mars 2013 17:27:33, Stefan Lippers-Hollmann a écrit :
> 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.

Yes this one. I had a vague memory of lirc being installed for me with KDE but 
I wasn't sure I could trust my memory. Thank you for the apt-rdepends foo :)

> 
> […]
> 
> 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.

Then I agree with you this bug should probably be wheezy-ignored instead of 
fixed. Does the release team agree with this analysis?

> 
> Regards
> 	Stefan Lippers-Hollmann

Best regards,

Thomas
-------------- 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/b1241b26/attachment.pgp>