IMO the root problem if this breaks is mixing of autoprobe data with user configuration. We need to fix it by unmixing those things, not by breaking autoprobe or losing people's config files. Here is the basic flow you want: autoprobe and write out automated data about devices and drivers -> apply user-provided overrides and edits to autoprobed information -> autodetermine reasonable behavior in light of device details -> apply user-provided overrides and edits to default behavior -> invoke behavior So a concrete example: autoprobe ethernet card model Foo with details blah blah -> user wants to use alternate driver or work around hardware bug, said override data loaded -> autodetermine that if a link is present device should be brought up with dhcp -> user has specified that device should only be brought up manually -> device is now configured to come up manually with alternate driver Or whatever, you see the point. It's easy enough to see that we can have whitelists/blacklists inserted into the flow, so e.g. OS vendors or OEMs can provide overrides as well. The same basic idea is where we want to be going with X server configuration: the config file should contain only a delta from the default behavior. Or for that matter, something like "profile.d" is the same basic idea. Don't mix the automatically-created data, the vendor-provided data, and the site local data. I think it's fine to switch the default to autoprobe always in rawhide, it will encourage someone to fix the root problem ;-) but we probably can't ship with autoprobe until we unmix data from distinct sources. Havoc