#1 local repositories

[Anonymous]

You may already have considered this. But my
suggestion would be to support a local respository(ies)
as a fallback. This should be used for local hardware
detection and loading on install and when I replace my
network card as well (if I have the module but don't
have it loaded, this should configure it).

Don't listen to naysayers, this is a great idea. The
greatest benefit isn't really that it pulls the drivers
preventing users from having to hunt them down, but
that it eliminates the need for users to have to try to
figure out the correct module in the firstplace. For
instance when installing a Clie the least intuitive
choice of module to load would be the palm visor module.

Unfortunately there is alot of this going on in the
open source world, since a device is similar it's added
to the original module instead of having it's own.

[Nobody/Anonymous]

Logged In: NO

If your wanting to do what I think, thats already possible..
Driver On Demand allows a list of servers in
/etc/driverondemand.conf.. Of course though, at the moment
though, you'll also need a local keyserver running ,
otherwise it wont work (without setting security insecure at
least). The thing about local respositories though is that
you dont get up to date information on compromised keys that
easily, unless I have a mechanism to ensure they are up to
date..

I'll have to think about this though.. It works well for APT
though, and other package management systems.. Until then
you can just get a server snapshot off a server, set your
/etc/driverondemand.conf to include that local server, and
do it like that... Not sure when I will get around to doing
something to properly snapshot a DB.. but at the moment, for
local installs, a tar cfvj bleh.tar.bz2 devices/ will
generate a copy of the db, that will work locally..

[Andrew Luecke]

Logged In: YES
user_id=576923

btw.. that nobody was me... sorry about that, wasn't logged in