[packagekit] udev installing firmware? insanity or super cool?

[David Zeuthen]

On Fri, 2008-03-14 at 02:12 +0100, Klaus Kaempf wrote:
> * Richard Hughes <hughsient at gmail.com> [Mar 13. 2008 22:40]:
> > On Thu, 2008-03-13 at 22:18 +0100, Adrien BUSTANY wrote:
> > > That'd be great, really. Your "implementation" seems sane to me... Again 
> > > though, we have that name convention... All the distros have to call the 
> > > package with the same name. But distros can patch that.
> > 
> > Well, they could patch, or we could just install the package that
> > satisfies a filename, as this should be fairly common between distros.
> 
> This still requires to maintain a "deviceid:firmware-filename" list.
> 
> (open)SUSE kernel drivers publish the module's supported device id
> through 'modalias' regexps.
> See http://en.opensuse.org/Software_Management/Dependencies/Hardware
> 
> Based on this information, the PackageKit backend should be able to
> resolve a device id to an actual package name.

Yes, I've been mentioning similar schemes on this list earlier for
codecs which is basically the same thing. Check the archives.

My position is that I think a general utility in PackageKit would be for
an application (such as a firmware downloader or a media player) to be
able to call PackageKit like this

 PackageKit.NeedsPlugin (type, classification)

where 

 type = firmware | driver | mediacodec | ...

and classification would depend on the type

 type_mediacodec = <mime-type-of-codec-or-something>
 type_firmware = <name of file missing in /lib/firmware>
 type_driver = <modalias>

Different PackageKit backends would implement different ways of actually
finding the packages that fullfill the request. You obviously want to
sit down with domain experts for each type; I mean there's a reason I
handwaved about type_mediacodec (e.g. talk to the gstreamer people).

Of course one key thing here is that NeedsPlugin() is on the _session
bus_ meaning that it can put up dialogs to interact with the user,
asking for his consent, authentication and all that Jazz. 

Alternatively you can put it on the system bus and the PackageKit daemon
will queue up the request by itself and present it to the user as soon
as a capable enough PackageKit client app pops up (e.g. pk-update-icon
or something). I don't know.

The morale here is to do this in a generic way. It's fine probably just
to start with firmware (because classification is so easy; it's simple a
name) or whatever but if you do then at least make the interfaces
somewhat generic so it's easy to add e.g. codec support.

Of course, as I said on davej's blog, the whole premise of this idea
(ooo, we save 35kb by not installing firmware etc.) is shady and
slippery but, eh, what the hell.

     David