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
User-Agent: Build Identifier: 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 ``rpmdb-fedora''. http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY ``/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.'' http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA ``/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. http://www.pathname.com/fhs/pub/fhs-2.3.html#THEVARHIERARCHY ``/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.'' http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION ``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 spooled data.'' Reproducible: Always 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 owners.
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 done.
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 becomes 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.