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

[Michael Biebl]

2013/6/17 Kay Sievers <kay at vrfy.org>:
> On Mon, Jun 17, 2013 at 6:41 AM, Martin Pitt <martin.pitt at 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?