Bug 136019

Summary:	[FHS] [read-only /usr] rpm(?) creates files not tracked by RPM in /usr/lib/rpmdb/i386-redhat-linux/redhat/
Product:	[Fedora] Fedora	Reporter:	Daniel Reed <djr>
Component:	rpmdb-redhat	Assignee:	Elliot Lee <sopwith>
Status:	CLOSED RAWHIDE	QA Contact:	Mike McLean <mikem>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	nobody+pnasrat, sopwith
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-03-22 04:39:42 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	124120

Description Daniel Reed 2004-10-16 20:34:50 UTC

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:

Comment 1 Jeff Johnson 2004-10-16 23:33:34 UTC

The __db* files are a Berkeley DB environment.

If that doesn't float your FHS boat, then talk to the rpmdb-foo
owners.

Comment 2 Tim Powers 2004-10-21 20:05:26 UTC

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.

Comment 4 Elliot Lee 2004-12-21 17:55:46 UTC

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.

Comment 5 Elliot Lee 2005-03-22 04:39:42 UTC

rpmdb is dead.