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 ** Changed in: landscape-client Milestone: None => 11.02 ** Changed in: landscape-client Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/708502 Title: Please drop hal dependency -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
