Bug 1226379 - /etc/udev/hwdb.d is not owned by any package
Summary: /etc/udev/hwdb.d is not owned by any package
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-05-29 15:19 UTC by Michael Schwendt
Modified: 2015-07-14 15:31 UTC (History)
7 users (show)

Fixed In Version: systemd-219-19.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-07-14 15:31:45 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 907719 0 unspecified CLOSED /usr/lib/systemd/system/remote-fs-pre.target.wants/ unowned directory 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1226704 0 unspecified CLOSED TRACKER: files in /etc/udev/rules.d 2022-09-13 17:41:14 UTC

Internal Links: 907719 1226704

Description Michael Schwendt 2015-05-29 15:19:40 UTC
# rpm -qf /etc/udev/hwdb.d
file /etc/udev/hwdb.d is not owned by any package

# rpm -qf  /usr/lib/udev/hwdb.d
systemd-219-15.fc22.x86_64

Comment 1 Zbigniew Jędrzejewski-Szmek 2015-05-29 20:35:12 UTC
This directory is neither part of the rpm, nor is is created automatically. In principle we could add it as %ghost, but there's many directories which /could/ be created, but most of the time are not. Adding them all as %ghost would add lots of clutter for minor gain.

Comment 2 Michael Schwendt 2015-05-30 15:08:44 UTC
It is a directory udevadm accesses by default:

  $ strings $(which udevadm)|grep hwdb|grep etc
  /etc/udev/hwdb.d
  /etc/systemd/hwdb/hwdb.bin
  /etc/udev/hwdb.bin

It is common practise to include such default directories in the RPM package %files lists.

Comment 3 Zbigniew Jędrzejewski-Szmek 2015-05-30 20:00:23 UTC
My point is that although it is one of the directories potentially used by systemd, so are many many other directories. If a package has a few directories like that is manageable and useful to ship empty directories or %ghost them. But for every configuration path, systemd checks /usr/lib, /run, and /etc. For unit files it also checks .d, .wants, .requires (each one in /usr/lib, /run, and /etc too). In practice only a very small subset is ever created. I feel that creating all those rarely used directories is not useful, because it would be harder to find the ones that are actually used. So we ship or %ghost those that are commonly used, and just document the rest.

Coming back to /etc/udev/hwdb.d: it is one of those directories which are probably very rarely used. How often do people create their own hwdb entries? I'd think that outside of developers of systemd and people who work on input devices, not often.

Comment 4 Michael Schwendt 2015-05-31 06:14:53 UTC
That's disappointing to hear. I'm surprised that I need to try so much to convince you.

I've used this directory when following instructions [from somebody at Red Hat] to correct the hwdb entry for my mouse. Beyond those instructions, it is also documented within "man udev" as a directory for local administration:

| RULES FILES
|        The udev rules are read from the files located in the system rules
|        directory /usr/lib/udev/rules.d, the volatile runtime directory
|        /run/udev/rules.d and the local administration directory
|        /etc/udev/rules.d. 

Wouldn't it much easier to simply remove that directory from udevadm and the documentation then?

Comment 5 Michael Schwendt 2015-05-31 06:41:53 UTC
man udev
| HARDWARE DATABASE FILES
|        The hwdb files are read from the files located in the system hwdb
|        directory /usr/lib/udev/hwdb.d, the volatile runtime directory
|        /run/udev/hwdb.d and the local administration directory
|        /etc/udev/hwdb.d.

Comment 6 Michael Schwendt 2015-05-31 06:42:51 UTC
$ rpm -qf /etc/udev/rules.d
systemd-216-24.fc21.x86_64
$ rpm -qf /etc/udev/hwdb.d
error: file /etc/udev/hwdb.d: No such file or directory

Contradictory.

Comment 7 Zbigniew Jędrzejewski-Szmek 2015-05-31 18:37:44 UTC
You have a point there. But there's a reason for the difference: in the past files were routinely shipped in /etc/udev/rules.d. Even now 42 packages ship file there. This is a bug, and they should be moved to /usr, or removed, but the directory *is* being used. For /etc/udev/hwdb.d, nothing should ever ship there.

We document many more directories than we ship or that users might create:
/etc/udev/hwdb.d is borderline, /run/udev/hwdb.d is imho beyond the border. What rule would you use to decide which directories should be shipped in the rpm, which should be %ghosted, and which should be ignored?

Some candidates: find $(rpm -ql systemd|grep /system/) -type f -printf '{/usr/lib,/run,/etc}systemd/system/%f.{wants,requires,d}\n'

Comment 8 Michael Schwendt 2015-05-31 20:08:27 UTC
I would expect  /etc/udev/hwdb.d  to be available by default (with proper ownership and access permissions!) just like /etc/cron.d, /etc/grub.d, /etc/yum.repos.d and similar configuration directories to be used by the admin.

On the contrary, /usr/lib/udev/hwdb.d  is for system installation, i.e. files installed as part of RPM packages.

One dir for packages. One for the admin. No conflicts. If I stored a file 70-mouse.hwbd in /usr/lib/udev/hwdb.d, any package or update could replace it.

%ghost hides a file from RPM based integrity checks, which is less useful for empty directories. It is more useful for entirely runtime generated files.

Comment 9 Zbigniew Jędrzejewski-Szmek 2015-05-31 20:14:13 UTC
I agree with everything you say, but you provide the justification for one directory. What about all the other directories? See the list from comment #c7.

(BTW, there's a list of more potential directories. Quoting NEWS for systemd-218:
          All systemd programs that read standalone configuration
          files in /etc now also support a corresponding series of
          .conf.d configuration directories in /etc/, /run/,
          /usr/local/lib/, /usr/lib/, and (if configured with
          --enable-split-usr) /lib/.  In particular, the following
          configuration files now have corresponding configuration
          directories: system.conf user.conf, logind.conf,
          journald.conf, sleep.conf, bootchart.conf, coredump.conf,
          resolved.conf, timesyncd.conf, journal-remote.conf, and
          journal-upload.conf.  Note that distributions should use the
          configuration directories in /usr/lib/; the directories in
          /etc/ are reserved for the system administrator.
)

Comment 10 Michael Schwendt 2015-05-31 20:23:47 UTC
/usr/local  is nothing we care about at the distribution level except for the basic tree inside the "filesystem" package. We don't put any packaged files into /usr/local ever.

/etc : YES

/run : volatile, tmpfs => that sounds like space not used by human-beings but only by software -- e.g. generating fire'n'forget files at runtime, which don't survive a reboot. Caution! The software must be intelligent enough to create missing dirs before trying to store files in there. ;)

/usr/lib : YES -- used by the distribution's packages

Comment 11 Zbigniew Jędrzejewski-Szmek 2015-06-01 02:41:18 UTC
I feel like we're talking past one another :(

(In reply to Michael Schwendt (Fedora Packager Sponsors Group) from comment #10)
> /usr/local  is nothing we care about at the distribution level except for
> the basic tree inside the "filesystem" package. We don't put any packaged
> files into /usr/local ever.
Agreed. I never mentioned /usr/local.

> /run : volatile, tmpfs => that sounds like space not used by human-beings
> but only by software -- e.g. generating fire'n'forget files at runtime,
> which don't survive a reboot. Caution! The software must be intelligent
> enough to create missing dirs before trying to store files in there. ;)
Yes, everything you say is true. But it doesn't answer the question whether those directories should be %ghosted in the rpm or not. 

> /etc : YES
> /usr/lib : YES -- used by the distribution's packages
OK, but again, even if we stick to /etc only, the question is which of approximately 423 directories listed in comment #c7 and 11 directories in #c9 should be created in systemd.rpm.

So far our rule was: we create those directories in which we ship files, or which are commonly used. We %ghost directories and files which will be created at runtime, e.g. in /run.

Comment 12 Michael Schwendt 2015-06-01 10:00:59 UTC
> I never mentioned /usr/local.

Of course you did in comment 9 as part of /usr/local/lib/

/usr/local is just the root of that tree, because it's an own special hierarchy in the FHS. It's outside the scope of the distribution's packages. There's not even a guarantee that directories within it are considered at all, such as /usr/local/lib* which is not in runtime linker's search path by default. Or /usr/local/etc which is not loaded from either.

Typically, the local admin needs to build software specifically to run from within /usr/local and read files within /usr/local/etc instead of /etc, or whether to override /etc contents with contents from /usr/local/etc if a program supports that.

That's completely different from software that looks at various dirs _by default_ and gives the dirs different priority as to override eachother. Documented dirs that are to be used for local administration/configuration.


> it doesn't answer the question whether those directories should
> be %ghosted in the rpm or not. 

The one I mention ought to be included in the package normally, i.e. with proper ownership and access permissions.

A directory that has highest priority at runtime (and overrides the files within other directories) is "visited" by the software with a file-exists check anyway.

%ghost should be used as a last resort for runtime generated files, where no default is available and where RPM verify options don't matter (=> external file integrity checking tools may handle such files).


> the question is which of approximately 423 directories listed in
> comment #c7 and 11 directories in #c9 should be created in systemd.rpm.

Unfortunately, you're dragging the topic into a completely different direction from what I had reported. This bug report is about the udev related tools and files and what is documented in the manual pages. Not limited to "man 7 hwdb". It is *not* about systemd's very own tree of where it stores (or may store) files in hundreds of dirs. The complexity of such a tree is an entirely different problem space, especially if it's below /usr/lib and manipulated by tools. Btw, users/admins are more likely to mess within that tree, if there is no corresponding tree below /etc - the place where configuration takes place.

A missing documented directory is an inconsistency and a sign of an unclean/unpolished installation. Admins follow the documentation, and the advertised dirs are not even present. It doesn't show up in "rpmls systemd|grep ^d" either when learning about the directory usage of that package. That's bad.

There would not need to be a "filesystem" package at all, it would not need to include an empty /etc/bash_completion.d either. More examples: /etc/exports.d, /etc/depmod.d


> So far our rule was:

That complicates matters. One size doesn't fit all.

And here's a violation of that rule:

  $ rpm -qf /etc/binfmt.d
  systemd-219-15.fc22.x86_64

  $ repoquery --whatprovides /etc/binfmt.d/\*
  ksh-0:20120801-24.fc22.x86_64

Comment 13 Zbigniew Jędrzejewski-Szmek 2015-06-02 01:17:44 UTC
OK, nevermind about /usr/local. It was mentioned in the quote, but I wasn't saying that it should be part of the rpm.

For me there isn't a particularly big difference between udev and the rest of systemd. But I won't argue the point further. You are correct under normal rules /etc/udev/hwdb.d would be included in the rpm. I change the spec to do that now in rpm.

Comment 14 Fedora Update System 2015-07-08 02:35:44 UTC
systemd-219-19.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/systemd-219-19.fc22

Comment 15 Fedora Update System 2015-07-10 19:17:58 UTC
Package systemd-219-19.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-219-19.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-11332/systemd-219-19.fc22
then log in and leave karma (feedback).

Comment 16 Fedora Update System 2015-07-14 15:31:45 UTC
systemd-219-19.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.