Red Hat Bugzilla – Bug 136019
[FHS] [read-only /usr] rpm(?) creates files not tracked by RPM in /usr/lib/rpmdb/i386-redhat-linux/redhat/
Last modified: 2007-11-30 17:10:52 EST
After an installation of Fedora Core rawhide, an unknown process modifies files
in the path ``/usr/lib/rpmdb/i386-redhat-linux/redhat/''.
``/usr/lib/rpmdb/i386-redhat-linux/redhat/'' is owned by the package
``/usr is the second major section of the filesystem. /usr is shareable,
read-only data. That means that /usr should be shareable between various
FHS-compliant hosts and must not be written to. Any information that is
host-specific or varies with time is stored elsewhere.''
``/usr/lib includes object files, libraries, and internal binaries that are not
intended to be executed directly by users or shell scripts.''
The files __db.001 through __db.003, in this hierarchy, do not appear to be
object files, libraries, nor internal binaries, but data or temporary files.
They are also not tracked by package management as they were [apparently]
generated or modified during run time and left unassociated with the package
they were generated by. As the data appears to be regenerated on the fly, it may
be best suited for storage in the ``/var/lib'' hierarchy.
``/var is specified here in order to make it possible to mount /usr read-only.
Everything that once went into /usr that is written to during system operation
(as opposed to installation and software maintenance) must be in /var.''
``This hierarchy holds state information pertaining to an application or the
system. State information is data that programs modify while they run, and that
pertains to one specific host. Users must never need to modify files in /var/lib
to configure a package's operation.
State information is generally used to preserve the condition of an application
(or a group of inter-related applications) between invocations and between
different instances of the same application. State information should generally
remain valid after a reboot, should not be logging output, and should not be
Steps to Reproduce:
The __db* files are a Berkeley DB environment.
If that doesn't float your FHS boat, then talk to the rpmdb-foo
I think I agree with the submitter on his FHS points. Jeff: Is there anything which needs to be done other
than changing the paths included in the packaging, and also within the macros file?
With that said, I don't think this is a candidate to be fixed in the FC3 timeframe. it's too short until it's
The __db files do get placed there if the user has write access when
using the rpmdb, but write access should not be necessary to make use
of the rpmdb, so the spirit of the FHS is not violated. With that, it
It's a one line change to move the files from /usr to /var in the
future - switching isn't hard. The main question is whether it is
worse to have some small extra junk files appear under /usr when /usr
is writeable, or to have / be filled up due to a whole bunch more data
being placed on that partition. Since the use of a small partition for
/ is not uncommon, keeping the data on /usr seems to make more sense.
rpmdb is dead.