On Fri, Jul 5, 2013 at 11:05 PM, Tom Gundersen <t...@jklm.no> wrote: > On Fri, Jul 5, 2013 at 10:04 PM, Michael Biebl <mbi...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel