Comment 1 for bug 708502

Martin and I talked about it. The proposed idea of making 'hal' a
'Suggests' and conditionally enabling the hardware plugin if HAL is
available sounds like the best path forward until we have the time to
migrate to something better (udev, for example).

<jkakar> pitti: We're just talking about what to do about the HAL dependency in landscape-client.
 Re: bug #708502
<ubottu> Launchpad bug 708502 in landscape-client (Ubuntu) "Please drop hal dependency" [High,New] https://launchpad.net/bugs/708502
<jkakar> pitti: We don't really have the time/capacity to migrate to udev right now.
 pitti: We're wondering about making hal a 'Suggests', so that the client can be installed without it, and making some tweaks to the code so it won't blow up if HAL isn't there.
 pitti: The question is, will the hal package be moving to universe?
<pitti> jkakar: I was actually quite surprised that it still used it; I thought we already talked about it many years ago
 jkakar: I hope that we can move it to universe in natty or n+1
<jkakar> pitti: We did, we just haven't made time for it... too many bigger fires to deal with. :(
<persia> Riddell, Looks like upstream 1.1 is out, but still has the dependency on HAL, and I don't see any halsectomy related items on the 1.2 roadmap. qtmobility can be compiled to not use HAL, with "reduced functionality". I don't know of anyone actively using these APIs though, so I'd be tempted to compile with the reduced functionality (unless you know a user my apt-cache isn't finding).
<jkakar> pitti: Okay, so there's a chance it won't make it for natty.
<pitti> persia: it's not a compile-time thing; it only talks to the dbus interface
<persia> pitti, Is there a reason to move to universe, or can we just drop it?
<jkakar> pitti: I guess very few packages actually use it, right?
<pitti> persia: i. e. simply runtime
<persia> pitti, There's a compile-time option to tell it not to ask DBus about HAL.
 (or else I'm reading the docs wrong)
<pitti> jkakar: it's qtmobility and landscape-client, the rest was fixed or will be in the next days
<pitti> persia: right, but ideally it would just fail gracefully if hal isn't running (I haven't checked)
<pitti> jkakar: out of interest, what do you use it for?
<jkakar> I suppose one option for us is to make hal a Suggests and do a conditional import... if hal is unavailable (because the package is gone entirely) the hardware inventory will be simply unavailable.
 pitti: We pull the entire HAL device tree and send it to the server. We provide a view of that data to our users.
<pitti> jkakar: is that merely for display purposes, or do you actually do something with the data?
<jkakar> pitti: Honestly, the functionality we have isn't so useful.
 pitti: Merely for display purposes.
 pitti: But we don't have the time to replace it with something better right now, so we're trying to figure out how to keep it working if possible.
<pitti> jkakar: the hal tree is by and large the sysfs tree
<jkakar> pitti: True.
<pitti> an udevadm info --export-db usually gives enough info about the hardware, at least in the bugs that I am looking into
<jkakar> pitti: One issue is that udev provides really crappy data on <lucid.
 pitti pingbat Pici
<pitti> and given that hal likes to break stuff, and at least slows things down (double-probing), I'd rather not force it on our users any more
<jkakar> pitti: We need to support dapper for a few more months, but more importantly, we have a number of hardy users and we want to provide a good experience for them if possible.
<pitti> jkakar: sysfs/udev on hardy should work just fine
<jkakar> pitti: Yep, agreed, getting rid of hal is the right thing to do. We don't want to block that. We just want to figure out if hal will be moving somewhere else (universe).
<pitti> jkakar: yes, to universe
<jkakar> pitti: It works fine, but the data it exposes is missing lots of interesting things. The data for lucid and newer is much better/richer.
<Riddell> persia: where is the 1.2 roadmap?
<persia> pitti, qtmobility does appear to fail gracefully, from a quick look at ./src/systeminfo/qsysteminfo_linux_common.cpp
<pitti> jkakar: but the more important thing than the component is that we don't really want to force users to get hal if they install landscape, as it changes the system behaviour
<jkakar> pitti: Cool. In that case I think what we'll do is make hal a 'Suggests' and, if people want it, they can install it from universe. We'll do a conditional import and disable the hardware plugin if hal isn't installed.
<persia> Riddell, http://bugreports.qt.nokia.com/secure/IssueNavigator.jspa?reset=true&jqlQuery=labels+%3D+mobility_roadmap+ORDER+BY+component+ASC,+key+DESC
<pitti> jkakar: that sounds great