2013/6/17 Kay Sievers <k...@vrfy.org>: > On Mon, Jun 17, 2013 at 6:41 AM, Martin Pitt <martin.p...@ubuntu.com> wrote: >> Lennart Poettering [2013-06-17 2:52 +0200]: >>> The file is supposed to be be built on the installed system so that >>> other packages or the admin can drop in additional hwdb files. And yes, >>> it is not a package manager controlled file, which is precisely why I am >>> saying it belongs to /etc, not /usr. >> >> (See my other response to Tom about details) >> >>> No, by placing it in /usr (or /lib, for old distributions which haven't >>> done the /usr merge yet) you break the rule that the files the systemd >>> package installs in /usr should be the same on all installations of the >>> same package version. >> >> It doesn't at the moment, as the file is in the package it is the same >> on all installations (of the same architecture). > > The hwdb files are overwritable/extendable the same way as udev rules > are, Admins can update add individual keys/values with files in /etc, > which will result in different binary databases. > > Udev is not the only package that will install the source files, the > hwdb files will be used like udev rules, sane scanner rules, gphoto > rules, upower stuff, ... should all use hwdb files instead of udev > rules in the future. > > Therefore, the binary database must be generated on the target host > system and never be shipped by the udev package.
I guess we can all agree that the cache file in /etc is not really nice and that /etc/ld.so.cache already exists, doesn't really make that better. A 5+ MB blob is really annoying, especially if you use tools like etckeeper. Putting the cache files in /lib (or /usr/lib), isn't really great either, even though we have some precedence here too, like /lib/modules/*/ or icon and gsettings cache files. What about this compromise: a/ udevadm hwdb --update should be run in postinst, i.e. do not ship a pre-generated cache file b/ let udevadm hwdb --update check, if /var or /var/cache is on a separate partition. If not, store the cache file in /var/cache/udev, /etc/udev otherwise c/ update udev to read from both locations, /var/cache having preference The only case, where this scheme would fail, is if you backup and restore a system to a different partitioning scheme. But I guess I could live with that, given that because of a missing hwdb.bin, we won't fail to boot. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel