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

[Lennart Poettering]

On Mon, 17.06.13 19:43, Michael Biebl (mbiebl at gmail.com) wrote:

> 
> 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.

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.