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