On Mon, 17.06.13 19:43, Michael Biebl (mbi...@gmail.com) wrote: > > 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.
I am pretty sure we really shouldn't do an automatism like that. This is very opaque to the user, easily appears random, and certainly deoesn't help uniformity, testability, or documentability. I though about moving /.readehad to /var in a scheme like this, too, a while ago, but I am pretty sure we shouldn't try to be too smart on things like that, and stick to one location and one location only. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
