Re: Usage of /var/lib for databases not properly described in policy
On Tue, 10 Aug 2010, Andreas Tille wrote:
> I just tried to give some advise about proper placement of database
> files in a Debian package and I was sure I could simply link to the
> relevant paragraph in policy but there is none. Is the usage of
> /var/lib/<pkgname> just a reasonable habit which is shared by
> postgresql, mysql and probably others and I could for instance
> invent a directory
>
> /var/my_super_duper_database
>
> and keep the data there? I do not actually intend to do so, but
> shouldn't this be fixed somewhere in the policy. FHS[1] is not
> giving any explicite advise here and so we can not relay on the
> predefinition there and thus should rather make our own.
FHS actually does define this. See Chapter 5, Purpose:
"Applications must generally not add directories to the top level of
/var. Such directories should only be added if they have some
system-wide implication, and in consultation with the FHS mailing
list."
Coupled with
"/var/cache is intended for cached data from applications. Such data
is locally generated as a result of time-consuming I/O or calculation.
The application must be able to regenerate or restore the data. Unlike
/var/spool, the cached files can be deleted without data loss."
and
"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."
Don Armstrong
--
Of course, there are cases where only a rare individual will have the
vision to perceive a system which governs many people's lives; a
system which had never before even been recognized as a system; then
such people often devote their lives to convincing other people that
the system really is there and that it aught to be exited from.
-- Douglas R. Hofstadter _Gödel Escher Bach. Eternal Golden Braid_
http://www.donarmstrong.com http://rzlab.ucr.edu
Reply to: