[systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc

[Kay Sievers]

On Fri, Jul 5, 2013 at 11:05 PM, Tom Gundersen <teg at jklm.no> wrote:
> On Fri, Jul 5, 2013 at 10:04 PM, Michael Biebl <mbiebl at gmail.com> wrote:
>> My very first idea was [1], to use /lib/udev for the cache file as
>> long as /etc/udev/hwdb.d was empty.
>> And as soon as files are added to /etc/udev/hwdb.d, the cache file is
>> generated in /etc/udev and udev will first try to read the cache file
>> from /etc and fall back to /lib
>> This would be rather simple to add. The cache file in /lib/udev would
>> still be perfectly shareable across hosts.
>
> Notice that the cache file still cannot be generated at build-time
> (which is why some object to keeping it in /lib). The reason being
> that it is (might be/will be) generated from files shipped with
> various other packages, so its contents depends on what other things
> you have installed.

It's really a short-sighted hack to put created files into /usr/lib/
and pretend nothing will need it otherwise, or nobody will need to
change it.

The database is the result of gathering information from more than one
place, and the database will need to be updated at every package
update shipping any hwdb data. Admin changes in /etc will also always
require a new database build.

Things like keymaps, sane-scanner usb IDs, gphoto USB IDs will all be
converted to use the hwdb stuff over time. All the current tools that
currently ship these huge udev rules files will need to convert away
from that.

If putting things like that in /etc is a problem, we should find a
better place to put things like that, not hack around in ways that
cannot work in the future.

Early boot tools need a way to store such created databases in the
root file system outside of /usr, the same way ld.so.cache wants it's
file there. The way the hwdb works is to have one database file not
many. Things that get overwritten are optimized-out at compile time,
not at runtime. And we are not really interested in introducing
significant overhead and complexity here, because we just have no
better place at the moment than /etc to store the database. There are
only a bunch of tools, basically only things that need to be able to
run before /var is mounted, so the exception to do that will not get
many more users over time.

Sure, you can patch it now to handle the current (not widely used)
state, but please don't be surprised when your hack breaks and when
things will not work as expected on your system. And I'm pretty sure,
it will not take long. :)

Kay