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
info.
>
> > 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
servers.
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
KC6LBJ
Reply to: