Created attachment 83316 [details] move-hwdb-to-lib-syslocal.patch It is annoying to have an empty hwdb.bin in /etc (bzip2 compresses to 1Mbyte insted of given 5Mbyte) Create a sub directory /lib/FOO (as also /lib/modules will not move to /usr) this is the alternative to /etc All of the following has a misunderstandable bias: FOO=boot FOO=init FOO=sys FOO=system(d) I would prefer /lib/syslocal as a place for local startup helpers.
wrong, /lib and /usr/lib can be read-only and that's valid configuration. it's not for dynamic data like hwdb.bin which root (and package manager at post install phase) can create at will by calling `udevadm hwdb...`
It's unfortunate, but there is currently no better place than /etc. It is dynamically created data, including config from /etc. /lib must not be used for that type of data. It would belong into /var, but that might not be availble. It's the same reason the ld.so.cache is in /etc. I'm closing this bug, because we don't have any better idea than what we currentllyi do.
(In reply to comment #0) > Created attachment 83316 [details] > move-hwdb-to-lib-syslocal.patch > > It is annoying to have an empty hwdb.bin in /etc > (bzip2 compresses to 1Mbyte insted of given 5Mbyte) I don't understand. Why do you have an empty hwdb.bin and what are you talking about? > I would prefer > /lib/syslocal > as a place for local startup helpers. While /etc is far from perfect, /lib is even worse. /lib is for read-only stuff that should get touched only by the package manager -- apps, libs, etc. hwdb.bin is more of machine-generated data that fits /var.
/locsys as a new standard root directory? - /vlib could be "virtual" - /vsys seems to be container related also - /libv could be an additional arch - /varlib or /varloc could be assumed an accident In times when all get temporary and virtualized the real place gets missing ...
We have /var for all "normal" tools to use. It should be only very few things that need var-like data on the rootfs, mainly only the things that are needed to mount /var, which is systemd/udev. I don't think that introducing a new top-level directory just for that is justified. Some directory below /etc which can be excluded from backups might be ok, but anything else does not look too convincing at the moment.
Isn't this a potential security risk vector ? Every admin "root" user in a fatal stress situation uses every tool available to search for the cause of system break down. We already have a bin /etc/ld.so.cache as someone pointed out. But these two binaries differ in a fundamental way: The contents of ld.so.cache is very dependend of local conditions. On the contrary hwdb.bin only depend on foreign id strings. This fact will provoke a sponsoring of Linux administration tools from cyber-war intelligence. Use case: (Perhaps better to not use the term n.s.a) The special chinese department will direct manufacturers to release their hardware with fitting strings. In a way their previously sponsored administration tools can get out of bounds ...
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.