[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: directory to store TLE files

On Wed, Feb 18, 2004 at 09:07:01AM +1100, Hamish Moffatt wrote:
> On Tue, Feb 17, 2004 at 01:50:40PM -0800, Rafael Skodlar wrote:
> > It depends on your definition of wrong but it's very likely they are
> > wrong.
> > 
> > What has /var/lib to do with application data storage? MySQL in
> > particular? lib is described as place to keep library files for C and
> > other programing languages. Since when is mySQL data file(s) such a
> > library?
> No, /var/lib isn't described as a place to keep library files.
> You might be confusing it with /usr/lib and /lib. Even /usr/lib is a
> mixture of both libraries and architecture-specific data files.
> (/usr/share is for architecture-non-specific data files.)
> Here's what the FHS says, which is authorative:
>        5.5  /var/lib : Variable state information
>        /var/lib -- Variable state information
>        +-<editor>  Editor backup files and state
>        +-misc      Miscellaneous state data
>        +-xdm       X display manager variable data
>        +-<pkgtool> Packaging support files
>        +-<package> State data for packages and subsystems
>        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 should 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) should 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.
>        /var/lib/<name> is the location that should be used for all distribution
>        packaging support.  Different distributions may use different names, of
>        course.

I never argued that. "Variable state" is status of some application and
not necessarily a database for example but that's not the point for this
discussion, I just mentioned it in response to mySQL example and
comparing it to practice in Unix and examples in manuals.

>        An important difference between this version of this standard and
>        previous ones is that applications are now required to use a
>        subdirectory of /var/lib.
> > Of course, others might disagree but keeping track of optionaly
> > installed apps for backup purposes is not easy if the files end up mixed
> > with default OS installation. When your apps become part of a
> > distribution then I see no problem with having them in non local /usr
> > structure.
> I'm not sure what your point is with all this. We are talking about
> satellite tracker applications supplied by Debian, so /var/lib is an
> appropriate place for those applications to store data.

Somebody brought up mySQL and I thought it was not a good example for
it. I do agree with you that /var/lib might be appropriate place for sat

> > That way backups become very simple.
> > 
> > /etc, /root, /home, /opt, /usr/local, /var
> > 
> > /var is for spool, log files and not application data storage IMO. Some
> /var is for variable data, which includes databases. Which other FHS
> directory would you suggest?

I don't agree with databases being there but other var stuff is OK. RH
used different structure some time back but it's a moving target and
I've seen stuff in all kind of places installed by "professional
organizations" not just OSS developers.

> > There was a reason for the current Unix file structure, see book UNIX
> > Power Tools, p.247.
> "apt-get install debian-policy" and read
> /usr/share/doc/debian-policy/fhs/*; it describes the policy we use on
> Debian and most distributions use.

Debian, just like other distros, have weird and unlogical ways of doing
things. Again, it's not my intension to discuss it here. It took me a
while, not more than 4 years ;-) to start using debian for serious

FHS as much as we would like it to become a standard is far from it.

My main point was that if it's installed by me, from tar or scripts then
I like to have a choice, i.e. store it in local place which is not mixed
with default OS stuff so that I do not need to trace and backup
individual files under God knows what. I switched many distributions on
the same system without a need to reinstall my /home in years.
/usr/local is my favourite place to keep later software installs and
the whole thing makes backups simple and effective.

If it's a simple apt-get install then I don't care as much where it ends
up as long as it doesn't violate security issues. That's all.

> Hamish
> -- 
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Rafael Skodlar

Reply to: