Subject | Re: [firebird-support] Setup script for Unix FHS 2.3 compliance |
---|---|
Author | Milan Babuskov |
Post date | 2006-07-26T18:34:07Z |
Ann W. Harrison wrote:
completely. (Although I haven't checked Gentoo of the mainstream ones).
http://www.tldp.org/HOWTO/HighQuality-Apps-HOWTO/
It is written by an IBM software architect and it really works.
One of the things is that /opt could be replaced with appropriate
directories. I don't know who is making Linux packages (Alex?) but I've
always stood aside as the need to have multiple versions of FB is much
stronger than the urge to standardize.
Debian, for example, builds their own FB packages and place it in
/usr/lib/firebird2. They place everything there, which is even worse
than having it in /opt, as it only "appears" standard.
If FB directory structure would ever change, the locations should be:
/usr/bin/fbmgr
/usr/bin/isql -> probably symlink to: /usr/lib/isql-firebird
/usr/bin/gsec (fbsec?)
/usr/bin/gbak (fbak?)
/usr/bin/fbserver
...other executables. For SuperServer they could probably go into
/usr/sbin but that's open for discussion.
/etc/firebird.conf
/var/log/firebird.log
/var/lock/isc_lock.hostname (fb_lock?)
/usr/lib/libfbclient.so
/usr/lib/libfbembed.so
etc.
This may seem like a complete mayhem to some Windows user, but that's
the way it should be done on *nix. Unlike Windows, you have package
manager to control all those files.
I have some Linux commercial software of my own and it installs in (and
uninstalls from) /usr/bin, /usr/sbin, /etc, /var/log, /var/lock and it
all works flawlessly. Using a tool like "checkinstall" enabled me to
have a single build system for .rpm, .deb and .tgz packages (for RedHat,
Mandriva, SuSE, Debian, Ubuntu, Slackware).
P.S. In case someone missed the point: What I just wrote is not direct
reply to what Ann wrote, but rather an analisys of the
directory-structure issue.
--
Milan Babuskov
http://swoes.blogspot.com/
http://www.flamerobin.org
>>My goal is to allow /opt to be read-only. The File system HierarchyDebian is probably the only distribution that really tries to follow it
>>Standard supports this by requiring any lock, configuration, and
>>variable files to be located outside of /opt.
>
> In case anyone confuses "Standard" with "common practice",
> here's a excerpt from the Wikipedia on the File System Hierarchy
> Standard:
completely. (Although I haven't checked Gentoo of the mainstream ones).
> The phrase "do not follow" is an understatement. On most LinuxFor my commercial software, I always refer to the following document:
> systems, you can't install a layered software product in the
> manner required by the FHS. Having a different installation for
> each Linux distribution is not fun.
http://www.tldp.org/HOWTO/HighQuality-Apps-HOWTO/
It is written by an IBM software architect and it really works.
One of the things is that /opt could be replaced with appropriate
directories. I don't know who is making Linux packages (Alex?) but I've
always stood aside as the need to have multiple versions of FB is much
stronger than the urge to standardize.
Debian, for example, builds their own FB packages and place it in
/usr/lib/firebird2. They place everything there, which is even worse
than having it in /opt, as it only "appears" standard.
If FB directory structure would ever change, the locations should be:
/usr/bin/fbmgr
/usr/bin/isql -> probably symlink to: /usr/lib/isql-firebird
/usr/bin/gsec (fbsec?)
/usr/bin/gbak (fbak?)
/usr/bin/fbserver
...other executables. For SuperServer they could probably go into
/usr/sbin but that's open for discussion.
/etc/firebird.conf
/var/log/firebird.log
/var/lock/isc_lock.hostname (fb_lock?)
/usr/lib/libfbclient.so
/usr/lib/libfbembed.so
etc.
This may seem like a complete mayhem to some Windows user, but that's
the way it should be done on *nix. Unlike Windows, you have package
manager to control all those files.
I have some Linux commercial software of my own and it installs in (and
uninstalls from) /usr/bin, /usr/sbin, /etc, /var/log, /var/lock and it
all works flawlessly. Using a tool like "checkinstall" enabled me to
have a single build system for .rpm, .deb and .tgz packages (for RedHat,
Mandriva, SuSE, Debian, Ubuntu, Slackware).
P.S. In case someone missed the point: What I just wrote is not direct
reply to what Ann wrote, but rather an analisys of the
directory-structure issue.
--
Milan Babuskov
http://swoes.blogspot.com/
http://www.flamerobin.org