Greetings members of RT,while greeting a NMU I proposed to do for the RC bug #655959, Stefan argued
that this bug might be better to be wheezy-ignored. Indeed, the bug isabout a prompt while doing an upgrade without user change but since lirc is not functional without user change, this situation is not really worth an NMU. Also, an automated upgrade would be possible in the more general case but the patch would be way more intrusive. Full details below and in the
bug log. Le vendredi 8 mars 2013 17:27:33, Stefan Lippers-Hollmann a écrit :
On Friday 08 March 2013, Thomas Preud'homme wrote: > Le vendredi 8 mars 2013 03:32:29, Stefan Lippers-Hollmann a écrit : > > 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. >
[about reverse dependencies, including recommends: I suggested that lirc could be installed automatically via a recommends but not used and havin an automatic
upgrade for such a case would be nice]
[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 youhave properly configured hardware), keyboard based navigation is onlypossible through selected frontends (e.g. xineliboutput-sxfe, onlythis special frontend can transport key presses to the vdr dæmon) orweb 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 thereasons for this are the supporting tools of the lirc package (mostlyirw, to generate button <--> keycode mappings, eventually irexec). Technically speaking, it might make sense to split out these toolsout of the lirc package, but that would leave lircd/ lircmd in a tinypackage of their own - something ftp-master doesn't exactly prefer. - kremotecontrol frontend for using remote controls Recommends: lircThis one is a tough call, isolated to kremotecontrol, the Recommends is correct, but kremotecontrol is a hard dependency of kdeutils (metapackage, 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 largercause 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 itwouldn't be a logical conclusion for these meta packages, but giventhe "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 wasonly suggested by kdetv, no hard dependencies or recommends.
[…]Pulling in the lirc (or inputlirc for that matter) package, which meansthe 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 properlyconfigured, which means at least selecting the driver type (out of ~60options - 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 devicesymlink) and the remote button <--> key event mapping is required. None of these can be detected automatically, as you can pair pretty much anyIR 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 IRremote, but still technically possible), it's a bit too strong for the kde-full --> kdeutils --> kremotecontrol dependency chain (but totallyfine 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 (buta 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 ofthe config overhaul is already present and fully functional in the packaging Vcs, only the automagical parts (and better documentation) are still in progress.
I think this justify adding a wheezy-ignore tag. Does the release team agree with this analysis? If not, there is a debdiff ready for upload.
Regards Stefan Lippers-Hollmann
Best regards, Thomas
Attachment:
signature.asc
Description: PGP signature