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
signature.asc
Description: This is a digitally signed message part.
