Detecting exploding batteries, part 2

David Zeuthen david at fubar.dk
Mon Sep 25 13:12:59 PDT 2006


On Mon, 2006-09-25 at 20:35 +0100, Richard Hughes wrote:
> On Mon, 2006-09-25 at 11:51 -0400, David Zeuthen wrote:
> > On the same noted the fdi files for USB music players shouldn't
> > either.
> > Perhaps we can combine this information and the hardware recall
> > information in a separate project and/or tarball called hal-hwinfo. 
> 
> If you create hal-hwinfo I don't mind porting over the fdi files and
> setting up the initial code - the more I think about this, the more sane
> it becomes. Adding it to the git tree (like what was done with
> PolicyKit) would allow existing HAL hackers to just switch repos.

OK, I'll create a hal-hwinfo repository. Danny seemed not to like the
name, so please post ideas for other names here. 

I'll also fix-up the usb csr stuff so as to separate the information
(the fact that a USB mouse supports usb csr) from the mechanism
(launching the usb csr addon).

> I figure (IMO):
> 
> * Distros don't want to update HAL in a stable distro because of all the
> new scary stuff like PolicyKit and all the latest crazy libparted stuff
> we like to come up with.[1]
> * Shipping a few updated fdi files as an update is an all-together less
> scary thing in a stable distro.

Right. So, starting from 0.5.9 distributors will need two tarballs

 - hal-0.5.9; and
 - hal-hwinfo-20060925 (which will be noarch)

where I've noted the intent to use the date as the version number for
the latter. 

Distributors are free to update the latter as often as they want and
they will probably just ship git snapshots of hal-hwinfo anyway. We
probably want all the suspend / hibernate quirks in the latter too.

If anyone is opposed to this please scream "bloody murder" or something
and explain why - it's not unlikely I've missed something. Thanks.

     David




More information about the hal mailing list