locatedb should be in /var/lib/misc not /var/lib/locate for FHS compliance

[brandon_peirce@…]

Admitedly FHS 2.3 wording leaves room for discussion, but after careful reading the most likely interpretation is that locatedb should be in /var/lib/misc.

​http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBMISCMISCELLANEOUSVARIABLEDATA describes (briefly) the /var/lib/misc directory. The endnote 39 provides further explanation: "This hierarchy should contain files stored in /var/db in current BSD releases. These include locate.database and ..." The use of the word "hierarchy" instead of "directory" is IMO the part that opens room for discussion (do they mean /var/lib hierarchy?). However, the endnote 39 is clearly attached to the paragraph describing /var/lib/misc and I interpret this to mean that locatedb should be in /var/lib/misc.

If my argument is accepted then the configure switch in Ch 6.32 Findutils 4.2.28 should be changed from --localstatedir=/var/lib/locate to --localstatedir=/var/lib/misc

[Matthew Burgess]

Thanks very much Brandon. I agree with your interpretation of the FHS, so I've committed a fix for this in #1869.

[Matthew Burgess]

Reopening as r7781 was incomplete (it didn't remove the creation of /var/lib/locate in "Creating Directories" and other interpretations of the FHS are possible (e.g. Greg Schafer points to ​http://www.pathname.com/fhs/pub/fhs-2.3.html#VARCACHEAPPLICATIONCACHEDATA).

[brandon_peirce@…]

/var/cache/locate is certainly functionally correct as per FHS-defined purpose. In some ways it's better than /var/lib/*. Only thing in favour of /var/lib/misc is that locate db is explicitly mentioned in the footnote there, and it's 'more traditional'. Guess there's no absolute right answer. Any idea other distro's put it? Slackware uses slocate (secure locate) and put's it in /var/lib/slocate, but thats hardly a reference.

[Matthew Burgess]

Yep, Greg also mentioned what other distros do at ​http://archive.linuxfromscratch.org/mail-archives/lfs-book/2006-September/019754.html.

I just performed a quick survey of a bunch of distros and none of the ones I checked use var/lib/misc. A number of distros have switched to slocate (secure locate) and Fedora has moved even further away to mlocate (merge locate). They vary between /var/lib/{s,m}locate. Of the ones who do use locate from findutils (Debian, Paldo), they are using /var/cache/locate.

[bdubbs@…]

I don't understand what is wrong with /var/lib/locate

From the FHS:

/var/lib : Variable state information

Purpose

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.

An application (or a group of inter-related applications) must use a subdirectory of /var/lib for its data. There is one required subdirectory, /var/lib/misc, which is intended for state files that don't need a subdirectory; the other subdirectories should only be present if the application in question is included in the distribution.

Specific Options

The following directories, or symbolic links to directories, must be in /var/lib, if the corresponding subsystem is installed:

Directory	Description
...
<package>	State data for packages and subsystems (optional)

These certainly sounds like the definition of the locate package to me as the state of the filesystem. As Matt indicated, the "normal" locateon is in /var/lib. In fact /var/cache is inappropriate because that directory is where "The application must be able to regenerate or restore the data." The example given is formatted man pages. In this case, locate does not generate the database -- updatedb does.

[brandon_peirce@…]

I have rethought the difference between 'state' data and 'cache" data. The cache data is stuff that's generated on the fly and the program will work fine if it's not there. Clearly locate(1) will not function correctly if locatedb is absent so it must go in /var/lib hierarchy not /var/cache.

/var/lib/locate is not really wrong, I just still think misc is better. For me the ticket can be closed if that's the general feeling. Why I think /var/lib/misc is firstly that "/var/lib/misc ... is intended for state files that don't need a subdirectory," while locatedb is just one uniquely-named file (IMO doesn't need a subdir) and secondly because of the explicit mention in footnoot 39 of FHS.

[dnicholson@…]

I just recently read this same section of the FHS because I was trying to figure out where the best place to put data for a package manager was. I came to the same conclusion as Brandon. cache' was for dynamic data that could go away, and lib' was for more permanent cached data.

I'm really not too concerned about where this ends up, but my general feeling is that somewhere in /var/lib is more appropriate. As Brandon says, locate's not gonna do much if it doesn't have a cached database.

Hmm. Maybe my thoughts should be on -dev to not draw the ire of Randy. :)

[bdubbs@…]

I'm going to mark this as wontfix based on the above discussion. The current location is FHS compatible and several other distros have the database in a directory (although the name varies.)

If desired, lets discuss this more on -dev and reopen the ticket if the consensus indicates a change should be made.