[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#655969: wheezy-ignore?

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 is
about 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 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.




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


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

Reply to: