Bug 1226379

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.

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.

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.

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?

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.

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

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'

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.

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

/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

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.

> 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

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.

systemd-219-19.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/systemd-219-19.fc22

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

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.