hal-info: making hardware updates easier

[Martin Owens]

Way to duplicate effort, I've been telling you guys about
dohickey.sourceforge.net for a long time now which includes a perfect
medium of updating hardware information. ok so it'll also contain
information about hardware that isn't useful to drive it; but it will
contain information that hal will find useful. it even has model
switching because more information is available about detected
hardware presenting better choices to users.

hal-info looks promising but it's still stunted and heavily in favour
of developer contributed information.

how will a user keep up to date information?
how will a user correct mistakes?
how is administration done on submitted data?
how do you keep your types structure up to date?

I could do with some help myself to be honest and we could come up
with a solution which is better than both projects because we both
have good points of view (and quite a bit of enthusiasm).

Best Regards, Martin Owens
On 11/7/06, Richard Hughes <hughsient at gmail.com> wrote:
> On Tue, 2006-11-07 at 01:36 +0100, Danny Kukawka wrote:
> > On Tuesday 24 October 2006 23:55, Richard Hughes wrote:
> > > The idea for versioning is for hal-info to use the date (e.g. 20061024)
> > > for it's version, and for hal to not depend on any particular version of
> > > hal-info. The idea being, hal is released every few months, but a new
> > > release of hal-info every couple of weeks would be no bad thing.
> >
> > Sorry, I forgot to comment, there is currently much work ...
>
> No probs, it seems like everyone is busy. Busy is good, as busy = job
> security :-)
>
> > If you suggest this would make it easier for a linux distributor to update the
> > fdi information files, I would say: normally no, it make it not easier.
> >
> > Yes you don't need to update the HAL package, but:
> >
> >  * if you e.g. and new keys/property you need to update the spec and this mean
> >    normaly you need to update the HAL package
>
> New keys added in hal-info should be ignored silently by older hal
> packages.
>
> >  * as a distributor you can't update the package for a relased version without
> >    QA work and this is at least the the same as if you update HAL, because you
> >    need to be sure that a change in the fdi-files change the behavior of HAL
> >    and the applications which use HAL.
>
> Sure, but the *risk* of breaking stuff has to be an order of magnitude
> less, and no new dependencies (like this crazy new PolicyKit thing ;-)
> are added. It's up to the distro to decide, but I think anything is
> easier than now.
>
> Cheers,
>
> Richard.
>
>
> _______________________________________________
> hal mailing list
> hal at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/hal
>