Bug 446180 – sys-fs/udev-196 generates binary database in /etc

• Product: Gentoo Linux
• Status: RESOLVED UPSTREAM

[Description Ulenrich 2012-12-05 23:21:41 UTC]

I really do often grep /etc recursively. 
Having a 5Mb bin in /etc tree reminds me of old times having /etc/X11/bin symlinking to /usr/bin. This was rejected long time ago by FSH standards. 
Under /etc there is NOT the place of generated files! 
(If you think of installed files - these config files should only have all commented out default values)!

There are enough possible places:
/var/lib
/lib

Please don't think of /usr for to hold it, because it is not thought of holding local adaptions!

Reproducible: Always

[Comment 1 Jeroen Roovers (RETIRED) 2012-12-05 23:38:18 UTC]

Please post your `emerge --info' output in a comment.

[Comment 2 Jeroen Roovers (RETIRED) 2012-12-05 23:38:54 UTC]

Also, `emerge -vpq sys-fs/udev'.

[Comment 3 Ulenrich 2012-12-06 00:39:05 UTC]

Hmm, I thought this is of hwids package, because of Changelog:

02 Dec 2012; Samuli Suominen <[e-mail]> hwids-20121202.2.ebuild,
  hwids-99999999.ebuild:
  Use ids-update.pl from systemd tarball to regenerate udev.bin binary

But hwdb USE flag of
# emerge -vpq udev
[ebuild   R   ] sys-fs/udev-196-r1  USE="acl gudev hwdb introspection keymap kmod openrc -doc (-selinux) -static-libs"

shows, this should be configured with udev? Or systemd?
# emerge -vpq systemd
[ebuild   R   ] sys-apps/systemd-196  USE="acl audit cryptsetup kmod lzma pam tcpd xattr -gcrypt -http -python -qrcode (-selinux) -vanilla" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7"

[Comment 4 Ulenrich 2012-12-06 00:47:40 UTC]

Excerpt from man udevadm shows:
---
udevadm hwdb [options]
       Maintain the hardware database index in /etc/udev/hwdb.bin.

       --update
           Compile the hardware dabase information located in /usr/l.....
           and store it in /etc/udev/hwdb.bin. This should be done with .....
           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 .... 
---
Without any option to put hwdb.bin at a self defined place.
This surely is an upstream bug: systemd/udev team is missing the taste for the right place!

[Comment 5 Ulenrich 2012-12-06 01:02:26 UTC]

Uups, Jeroen Roovers changed my thread title - it is about 
"/etc/udev/hwdb.bin"
annouingly is the wrong place for a generated 5Mb database file!
Please, if you feel the same, is someone bug it upstream?

[Comment 6 Diego Elio Pettenò (RETIRED) 2012-12-08 11:19:21 UTC]

Okay so this has nothing to do with hwids. The file is maintained by udev, and we really only generate it out of convenience so that you don't have to.

I'd also suggest bringing this upstream — it's their call where the file should be put. I guess the answer is going to be that if you want to be able to split /var out that, you can't put it in /var, so /etc sounds like a proper place.

OTOH if there is a way to generate it at src_compile() time, and then have it installed by the ebuild in /usr/share it might be a good thing.

[Comment 7 Samuli Suominen (RETIRED) 2012-12-09 05:41:20 UTC]

udev supports early boot without premounting /var, therefore leaving /etc the only logical place for the file:

http://cgit.freedesktop.org/systemd/systemd/commit/Makefile.am?id=1e1954f53386cb773e2a152748dd31c4d36aa2d8

file an upstream bug if you wish another system-level root directory like /share to be created

definately not an gentoo bug