Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
On Fri, Jul 5, 2013 at 2:32 PM, Michael Biebl mbi...@gmail.com wrote: 2013/7/5 Tom Gundersen t...@jklm.no: 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 I don't intend to do that, but instead run the update in postinst. I like the idea that /usr/lib (and /lib) should consist of static files. I don't feel that the database belongs there as it is too dynamic --- Shawn Landden +1 360 389 3001 (SMS preferred) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
On 06/14/2013 02:14 PM, Tom Gundersen wrote: On Fri, Jun 14, 2013 at 2:03 PM, Łukasz Stelmach l.stelm...@samsung.com wrote: It was 2013-06-14 pią 13:30, when Jan Janssen wrote: On 06/14/2013 01:08 PM, Tom Gundersen wrote: That said, I don't think libdir is appropriate as this data is not under the control of the package manager (as it is generated at install-time rather than at build-time, it would for instance not be suitable for sharing between hosts). I guess localstatedir would be another alternative, but the problem there is that it is not (necessarily) available during early boot when this db is needed. One could introduce a /cache where such files could be stored. Similar to how /run was introduced to fix a similar issue. The folder would be required to be available at boot time. What's wrong with /var/cache? /var may not be mounted at the time the caches are needed. So, why not mount /var also from the initramfs as we do with /usr already. Wouldn't that solve all the problems, and we can use /var/cache? :-) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
On Tue, Jun 18, 2013 at 9:15 AM, Harald Hoyer harald.ho...@gmail.com wrote: On 06/14/2013 02:14 PM, Tom Gundersen wrote: What's wrong with /var/cache? /var may not be mounted at the time the caches are needed. So, why not mount /var also from the initramfs as we do with /usr already. Because, so far we did not want to mandate an initramfs for a separate /var, which is unlike a separate /usr, a very common setup. Wouldn't that solve all the problems, and we can use /var/cache? It would be /var/lib, as it is not a cache; but sure, it would solve the problems. It would maybe significanlty complicate a few initramfs setups to reach /var, but sure, it would work. It would solve quite a few problems, but I'm not sure if that will be a generally accepted solution ... Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
Hello Tom, replying on-list again, if you don't mind. Tom Gundersen [2013-06-16 22:52 +0200]: On Sun, Jun 16, 2013 at 10:32 PM, Martin Pitt martin.p...@ubuntu.com wrote: We actually generate the hwdb during package build and ship hwdb.bin statically. The problem with that is that local configuration in /etc/udev/hwdb.d/ will be ignored, so it seems to me that the correct thing to do is to generate hwdb.bin in post-install. This bit striked me as overengineered, so for now our udev package doesn't even ship /etc/udev/. pci.ids or usb.ids aren't user-configurable, and there has never been a case that we heard of where the admin would have the need to change the name of a piece of hardware. Michael proposed a compromise where the hwdb.bin would be in /lib/udev, and as soon as there are files in /etc/udev/hwdb.d/ it would move the cache to /etc/udev/. I can't say I like that very much as it would introduce the same problem with just less predictability, but I want to mention it for the records. Anyway, Lennart's and your responses have demonstrated that putting the cache into /etc wasn't by accident but deliberate; that's fine, so let's keep it as it is, and we keep the patch downstream for now. As it is it is trivial to revert or change as it only changes statically shipped files in the package. Thanks for the discussion! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
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). Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
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. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
On Mon, 17.06.13 06:35, Martin Pitt (martin.p...@ubuntu.com) wrote: Anyway, Lennart's and your responses have demonstrated that putting the cache into /etc wasn't by accident but deliberate; that's fine, so let's keep it as it is, and we keep the patch downstream for now. As it is it is trivial to revert or change as it only changes statically shipped files in the package. I'd really prefer if Ubuntu wouldn't do its own thing for everything they possibly can. We try to push some of the more exotic device metadata into the respective packages and the developers of those packages should be able to rely on being able to drop in additional hwdb and have things work everywhere. If Ubuntu then goes and doesn't allow drop-ins and moves generation of these files to compile-time then you effectively make that impossible. And that's really uncool of you. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
On Mon, 17.06.13 06:41, Martin Pitt (martin.p...@ubuntu.com) wrote: 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). I cannot parse this. Let me try to explain this a different way: in RPM-speak the files in /etc should ideally either be %ghost'ed or %config'ed, and the ones in /usr should be neither. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
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
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
On Mon, Jun 17, 2013 at 7:43 PM, Michael Biebl mbi...@gmail.com wrote: 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. I agree with Lennart that we don't want this scheme, but rather something predictable. How about Colin's suggestion of putting hwdb.bin (and similar files that cannot always be in /var/cache) in /etc/cache? Or if anyone have the stomach for a huge fight, try to convince everyone of the usefulness of /cache? -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
On Mon, Jun 17, 2013 at 10:12 PM, Tom Gundersen t...@jklm.no wrote: How about Colin's suggestion of putting hwdb.bin (and similar files that cannot always be in /var/cache) in /etc/cache? Well, it's not a cache, it will not be re-created automatically like a cache, and it will not work with the file missing, it will just fail completely if the database is not there. Or if anyone have the stomach for a huge fight, try to convince everyone of the usefulness of /cache? I don't think the name is convincing. The rootfs is not really a place for cache files, it should be seen as read-only. Maybe etcetera is a nice name. :) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
On Mon, 17.06.13 22:12, Tom Gundersen (t...@jklm.no) wrote: The only case, where this scheme would fail, is if you backup and restore a system to a different partitioning scheme. I agree with Lennart that we don't want this scheme, but rather something predictable. How about Colin's suggestion of putting hwdb.bin (and similar files that cannot always be in /var/cache) in /etc/cache? Or if anyone have the stomach for a huge fight, try to convince everyone of the usefulness of /cache? Well, this is about very few files only. AFAICS only systemd/udev, kmod, ld.so need binary caches around this early during boot. It sounds a bit like overkill to introduce an entirely new root level hierarchy for that. Note that beyond caches there are a number of non-text-files in /etc. For example /etc/localtime, /etc/selinux/targeted/policy/policy.27, /etc/pki/*.db, /etc/aliases.db, /etc/ld.so.cache, /etc/prelink.cache and so on. I am not convinced that text file vs. binary file is the best check to decide whether something belongs in /etc or not. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
Lennart Poettering [2013-06-17 18:27 +0200]: We try to push some of the more exotic device metadata into the respective packages and the developers of those packages should be able to rely on being able to drop in additional hwdb and have things work everywhere. If Ubuntu then goes and doesn't allow drop-ins and moves generation of these files to compile-time then you effectively make that impossible. And that's really uncool of you. It wasn't really about not allowing things, but rather about making it easy to change or revert the current patch while this is being discussed. I wanted to fix the hwdb integration without adding a config file which then needs special treatment again for removal, as in dpkg config files are basically holy. If/once there are actually other packages wanting to add stuff there, we'll re-add the dynamic generation of course. But for now there is no reason to do so, it just wastes cycles, dramatically complicates the handling of the cache files, and adds an extra 5 MB to the install footprint. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
Lennart Poettering [2013-06-17 18:28 +0200]: On Mon, 17.06.13 06:41, Martin Pitt (martin.p...@ubuntu.com) wrote: 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). I cannot parse this. Let me try to explain this a different way: in RPM-speak the files in /etc should ideally either be %ghost'ed or %config'ed, and the ones in /usr should be neither. That's the situation with a dynamically created file as you have in current Fedora. But the current Ubuntu package just ships a static /lib/udev/hwdb.bin, thus it is perfectly shareable between installations and thus Tom's concern about not being a package-owned file doesn't apply. That's of course unrelated to the question whether we should move to dynamic creation of that file, at which point it wouldn't be suited very well in /lib (but still much better than in /etc). Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/17/2013 04:50 PM, Lennart Poettering wrote: On Mon, 17.06.13 22:12, Tom Gundersen (t...@jklm.no) wrote: The only case, where this scheme would fail, is if you backup and restore a system to a different partitioning scheme. I agree with Lennart that we don't want this scheme, but rather something predictable. How about Colin's suggestion of putting hwdb.bin (and similar files that cannot always be in /var/cache) in /etc/cache? Or if anyone have the stomach for a huge fight, try to convince everyone of the usefulness of /cache? Well, this is about very few files only. AFAICS only systemd/udev, kmod, ld.so need binary caches around this early during boot. It sounds a bit like overkill to introduce an entirely new root level hierarchy for that. Note that beyond caches there are a number of non-text-files in /etc. For example /etc/localtime, /etc/selinux/targeted/policy/policy.27, /etc/pki/*.db, /etc/aliases.db, /etc/ld.so.cache, /etc/prelink.cache and so on. I am not convinced that text file vs. binary file is the best check to decide whether something belongs in /etc or not. Lennart One of these days I plan on getting the policy file out of /etc and into /usr/lib/selinux, But any customizations by the admin or other packages would end up putting content into /etc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlG/fLgACgkQrlYvE4MpobPmQQCfeKqc3i3+JxaNMPFOxccPLesi q/EAniJUO5bYv+Ei9B5YPJpgZdtt3GoF =R+DF -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
2013/6/17 Lennart Poettering lenn...@poettering.net: 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. Why should this be relevant for the user? This is an internal implementation detail (btw, another reason, why it shouldn't be visible/accessible in /etc) -- 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
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
On Mon, 2013-06-17 at 19:43 +0200, Michael Biebl wrote: b/ let udevadm hwdb --update check, if /var or /var/cache is on a separate partition. If it was just udevadm, that wouldn't be so hard, but replicating the (what I expect to be fairly fragile) code to detect /var's paritioning scheme across any other components (e.g. fontconfig) would be ugly. Though I do keep coming back to the hwdb being a special case, since almost none of the other caches need to unify data from /usr and /etc. That does point out another potential solution - have two caches, one in /usr and one in /etc, and the /etc one is only created if there's anything to cache. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
On Fri, 14.06.13 12:26, Martin Pitt (martin.p...@ubuntu.com) wrote: Hello all, right now, udev stores its binary hwdb cache in /etc/udev/, which is ugly IMHO. This is neither user-editable nor configuration of any kind. It's just a cache file, and does not need to appear in backup, VCSes of /etc and the like. Can we move it to the libdir instead? Attached patch does that. No. As Tom pointed out, /usr is package manager territory and exactly the same on all machines (with the same set of package installed at least). It's supposed to be sharable between hosts. Doing recursive checksumming of /usr (modulo /usr/local) should yield the same results on all installations with the same package set. hwdb.bin is data that is generated dynamically on the host, and is possibly different on the various installation. It hence has no place in /usr. Of course /etc isn't particularly beautiful for this either, since it doesn't match *conceptually* what else is stored on that partition, but at least it has the right *availability*, *shareability* and *access* guarantees. /var doesn't work for this, as /var might be mounted too late. Introducing a new directory /cache or so would certainly work, but given that this problem exists only for the very minimal set of early-boot services this sounds like too big a change. And yeah, there are some other things in /usr that are currently generated on the host, and that should better be moved to /etc. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
On Sun, 16.06.13 22:32, Martin Pitt (martin.p...@ubuntu.com) wrote: Hello Lennart, Lennart Poettering [2013-06-16 8:36 +0200]: As Tom pointed out, /usr is package manager territory and exactly the same on all machines (with the same set of package installed at least). I wrote libdir, but what the patch actually uses udevlibdir, i. e. /lib/udev/. Well, distributions such as Fedora and ArchLinux actually did the /usr merge, hence my comment. It's supposed to be sharable between hosts. Doing recursive checksumming of /usr (modulo /usr/local) should yield the same results on all installations with the same package set. We actually generate the hwdb during package build and ship hwdb.bin statically. Right now there is no reason to ship the source files and build the DB in package postinst. I guess you generate it in the postinst, but that means that it's not a package manager controlled file either way, regardless of where it's stored. 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. Ubuntu is doing it wrong if they ship the file pre-built. Of course /etc isn't particularly beautiful for this either, since it doesn't match *conceptually* what else is stored on that partition, but at least it has the right *availability*, *shareability* and *access* guarantees. /lib has exactly the same availability/shareability/access properties AFAICS. Especially as the hwdb.bin file will be in exactly the same directory as the other udev helpers. 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. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
Am 16.06.2013 22:32, schrieb Martin Pitt: Of course /etc isn't particularly beautiful for this either, since it doesn't match *conceptually* what else is stored on that partition, but at least it has the right *availability*, *shareability* and *access* guarantees. /lib has exactly the same availability/shareability/access properties AFAICS. no, on Fedora it is a symlink to /usr/lib signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
On Fri, 2013-06-14 at 14:43 +0200, Tom Gundersen wrote: I'm working under the assumption that we want /usr one day to only contain static files generated at build-time (and hence under the control of the package manager), or at the very least any files in /usr not under the control of the package manager should be generated at install-time and be shareable between hosts using the same /usr. Er...what's the concrete problem here? Like you have /usr NFS mounted between two different hosts, and then add hardware configuration to one of them in /etc? I'd say it's clear here that the hwdb is under the control of the package manager (if one uses packages...yuck), and in e.g. RPM land it'd be a %ghost file. Where different components put generated files is not at all consistent of course. ldconfig - etc fontconfig - var (but it allows --with-cache-dir=/usr/lib/fontconfig/cache ) gtk-update-icon-cache - usr I'd say the answer here should be something like this: If the cache operates solely on data based in /usr, it should go in /usr. If it caches data from both /usr and /etc, it should go in /etc/cache (or something like that). And tools would have to learn to ignore /etc/cache. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
Hello all,
right now, udev stores its binary hwdb cache in /etc/udev/, which is
ugly IMHO. This is neither user-editable nor configuration of any
kind. It's just a cache file, and does not need to appear in backup,
VCSes of /etc and the like.
Can we move it to the libdir instead? Attached patch does that.
Thanks for considering!
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From 0d5c4f5d492d13c99ac1a8619ccb0dc3fe438d16 Mon Sep 17 00:00:00 2001
From: Martin Pitt martinp...@gnome.org
Date: Fri, 14 Jun 2013 12:21:38 +0200
Subject: [PATCH] udev hwdb: Store binary database in libdir, not in /etc
Storing huge binary files in /etc/ is ugly, as this is neither user-editable
nor configuration of any kind. This is just a cache file, and does not need
backing up.
Move it to udevlibexecdir instead.
---
Makefile.am| 2 +-
man/udevadm.xml| 6 +++---
src/libudev/libudev-hwdb.c | 10 +-
src/udev/udevadm-hwdb.c| 2 +-
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index a74c19d..a4db4a9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2179,7 +2179,7 @@ INSTALL_DATA_HOOKS += \
hwdb-update-hook
hwdb-remove-hook:
- -test -n $(DESTDIR) || rm -f /etc/udev/hwdb.bin
+ -test -n $(DESTDIR) || rm -f $(udevlibexecdir)/hwdb.bin
# --
TESTS += \
diff --git a/man/udevadm.xml b/man/udevadm.xml
index d0b257d..75a73c2 100644
--- a/man/udevadm.xml
+++ b/man/udevadm.xml
@@ -424,13 +424,13 @@
/refsect2
refsect2titleudevadm hwdb optionaloptions/optional/title
- paraMaintain the hardware database index in filename/etc/udev/hwdb.bin/filename./para
+ paraMaintain the hardware database index in filename/lib/udev/hwdb.bin/filename./para
variablelist
varlistentry
termoption--update/option/term
listitem
-paraCompile the hardware database information located in /usr/lib/udev/hwdb.d/,
-/etc/udev/hwdb.d/ and store it in filename/etc/udev/hwdb.bin/filename. This should be done after
+paraCompile the hardware database information located in /lib/udev/hwdb.d/,
+/etc/udev/hwdb.d/ and store it in filename/lib/udev/hwdb.bin/filename. This should be done after
any update to the source files; it will not be called automatically. The running
udev daemon will detect a new database on its own and does not need to be
notified about it./para
diff --git a/src/libudev/libudev-hwdb.c b/src/libudev/libudev-hwdb.c
index a56ad75..b8de7ed 100644
--- a/src/libudev/libudev-hwdb.c
+++ b/src/libudev/libudev-hwdb.c
@@ -271,30 +271,30 @@ _public_ struct udev_hwdb *udev_hwdb_new(struct udev *udev) {
hwdb-refcount = 1;
udev_list_init(udev, hwdb-properties_list, true);
-hwdb-f = fopen(/etc/udev/hwdb.bin, re);
+hwdb-f = fopen(UDEVLIBEXECDIR /hwdb.bin, re);
if (!hwdb-f) {
-log_debug(error reading /etc/udev/hwdb.bin: %m);
+log_debug(error reading UDEVLIBEXECDIR /hwdb.bin: %m);
udev_hwdb_unref(hwdb);
return NULL;
}
if (fstat(fileno(hwdb-f), hwdb-st) 0 ||
(size_t)hwdb-st.st_size offsetof(struct trie_header_f, strings_len) + 8) {
-log_debug(error reading /etc/udev/hwdb.bin: %m);
+log_debug(error reading UDEVLIBEXECDIR /hwdb.bin: %m);
udev_hwdb_unref(hwdb);
return NULL;
}
hwdb-map = mmap(0, hwdb-st.st_size, PROT_READ, MAP_SHARED, fileno(hwdb-f), 0);
if (hwdb-map == MAP_FAILED) {
-log_debug(error mapping /etc/udev/hwdb.bin: %m);
+log_debug(error mapping UDEVLIBEXECDIR /hwdb.bin: %m);
udev_hwdb_unref(hwdb);
return NULL;
}
if (memcmp(hwdb-map, sig, sizeof(hwdb-head-signature)) != 0 ||
(size_t)hwdb-st.st_size != le64toh(hwdb-head-file_size)) {
-log_debug(error recognizing the format of /etc/udev/hwdb.bin);
+log_debug(error recognizing the format of UDEVLIBEXECDIR /hwdb.bin);
udev_hwdb_unref(hwdb);
return NULL;
}
diff --git a/src/udev/udevadm-hwdb.c b/src/udev/udevadm-hwdb.c
index 3e849aa..65f08f0 100644
--- a/src/udev/udevadm-hwdb.c
+++ b/src/udev/udevadm-hwdb.c
@@ -569,7 +569,7 @@ static int adm_hwdb(struct udev *udev, int argc, char *argv[]) {
log_debug(strings dedup'ed: %8zu bytes (%8zu)\n,
trie-strings-dedup_len, trie-strings-dedup_count);
-if (asprintf(hwdb_bin, %s/etc/udev/hwdb.bin, root) 0) {
+if (asprintf(hwdb_bin, %s/ UDEVLIBEXECDIR /hwdb.bin, root) 0) {
rc
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
On Fri, Jun 14, 2013 at 12:26 PM, Martin Pitt martin.p...@ubuntu.com wrote: right now, udev stores its binary hwdb cache in /etc/udev/, which is ugly IMHO. This is neither user-editable nor configuration of any kind. It's just a cache file, and does not need to appear in backup, VCSes of /etc and the like. Can we move it to the libdir instead? Attached patch does that. I agree that the current location is a bit ugly (and so is e.g. /etc/ld.so.cache and /.readahead). That said, I don't think libdir is appropriate as this data is not under the control of the package manager (as it is generated at install-time rather than at build-time, it would for instance not be suitable for sharing between hosts). I guess localstatedir would be another alternative, but the problem there is that it is not (necessarily) available during early boot when this db is needed. -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
On 06/14/2013 01:08 PM, Tom Gundersen wrote: That said, I don't think libdir is appropriate as this data is not under the control of the package manager (as it is generated at install-time rather than at build-time, it would for instance not be suitable for sharing between hosts). I guess localstatedir would be another alternative, but the problem there is that it is not (necessarily) available during early boot when this db is needed. One could introduce a /cache where such files could be stored. Similar to how /run was introduced to fix a similar issue. The folder would be required to be available at boot time. Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
It was 2013-06-14 pią 13:30, when Jan Janssen wrote: On 06/14/2013 01:08 PM, Tom Gundersen wrote: That said, I don't think libdir is appropriate as this data is not under the control of the package manager (as it is generated at install-time rather than at build-time, it would for instance not be suitable for sharing between hosts). I guess localstatedir would be another alternative, but the problem there is that it is not (necessarily) available during early boot when this db is needed. One could introduce a /cache where such files could be stored. Similar to how /run was introduced to fix a similar issue. The folder would be required to be available at boot time. What's wrong with /var/cache? -- Łukasz Stelmach Samsung RD Institute Poland Samsung Electronics ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
On Fri, Jun 14, 2013 at 2:03 PM, Łukasz Stelmach l.stelm...@samsung.com wrote: It was 2013-06-14 pią 13:30, when Jan Janssen wrote: On 06/14/2013 01:08 PM, Tom Gundersen wrote: That said, I don't think libdir is appropriate as this data is not under the control of the package manager (as it is generated at install-time rather than at build-time, it would for instance not be suitable for sharing between hosts). I guess localstatedir would be another alternative, but the problem there is that it is not (necessarily) available during early boot when this db is needed. One could introduce a /cache where such files could be stored. Similar to how /run was introduced to fix a similar issue. The folder would be required to be available at boot time. What's wrong with /var/cache? /var may not be mounted at the time the caches are needed. -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
Hello Tom,
Tom Gundersen [2013-06-14 13:08 +0200]:
That said, I don't think libdir is appropriate as this data is not
under the control of the package manager (as it is generated at
install-time rather than at build-time, it would for instance not be
suitable for sharing between hosts). I guess localstatedir would be
another alternative, but the problem there is that it is not
(necessarily) available during early boot when this db is needed.
I tought about using /var/cache/ first as well, but /var might be on a
different partition. Hence I was using /lib/udev (i. e. udevlibdir) as
this guaranteed to be on the same partition as all the other udev
helpers.
Why is it a problem if a file in /lib is not under control of the
package manager? There are other files in /lib which are not, e. g.
/lib/modules/kernel/modules.dep{,.bin}. Also, if you share
/lib/udev/hwdb.d/, you can also share /lb/udev/hwdb.bin? How would
sharing be any different whether the cache file is in /etc or /lib?
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
Hi Martin,
On Fri, Jun 14, 2013 at 2:15 PM, Martin Pitt martin.p...@ubuntu.com wrote:
I tought about using /var/cache/ first as well, but /var might be on a
different partition. Hence I was using /lib/udev (i. e. udevlibdir) as
this guaranteed to be on the same partition as all the other udev
helpers.
Yeah, I agree it is not a viable solution either.
Why is it a problem if a file in /lib is not under control of the
package manager?
I'm working under the assumption that we want /usr one day to only
contain static files generated at build-time (and hence under the
control of the package manager), or at the very least any files in
/usr not under the control of the package manager should be generated
at install-time and be shareable between hosts using the same /usr.
(Substitute /usr with /usr, /lib, /bin and /sbin if you didn't
merge these dirs). You might of course disagree with this goal though
:)
There are other files in /lib which are not, e. g.
/lib/modules/kernel/modules.dep{,.bin}.
Yeah, that is another problematic example, though not as bad as at
least these files are generated only based on stuff in /usr.
Also, if you share
/lib/udev/hwdb.d/, you can also share /lb/udev/hwdb.bin? How would
sharing be any different whether the cache file is in /etc or /lib?
hwdb.bin is generated both from /etc/udev/hwdb.d/ (local) and
/lib/udev/hwdb.d/ (potentially shared) so hwdb.bin can not itself be
shared.
I'm afraid I don't see an elegant solution to the problem of caches
needed during early boot, short of doing something invasive as moving
/var/cache to /cache and mount it in the initramfs (as was done with
/run) or requiring /var itself to be mounted by the initramfs (as was
done with /usr). I can imagine strong opposition to both though...
-t
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
