Overview
setup - Instructions on how to compile and install Vitalnix Preface
There are three ways of getting Vitalnix installed. In the following descriptions, replace %version and %arch appropriately. But before we can get to the install instructions, reading the next paragraph is obligatory. Conflicting files
The Vitalnix package actually does "conflict" with other installed packages, as it provides some tools itself, which may already be installed by other -- possibly base system -- packages. This currently includes shadow[.rpm], in near future coreutils, and possibly util-linux. The Vitalnix RPM has no "Conflict" or "Obsolete" tag set, as these issues are not resolved yet. Any files installed -- either by RPM or source tree -- are named differently; they have been prepended a V, i.e. vgroupadd instead of just groupadd. Prerequisites
Vitalnix depends on some libraries, popt, libHX and libxml2.
Installing
From precompiled RPMOne is to install the precompiled RPM package; I recommend this for anyone just wanting to get it run.
This single command installs the RPM. Unless rpm returns some error, this is all there is to do. Precompiled RPM packages for i586-pc-gnu-linux and i686-pc-gnu-linux can be found on the Vitalnix Homepage. If, for some reason this does not work, i.e. because you have a different shared library versions than I do, I suggest reverting to RPM from specfile (see below). Program files will be installed in these paths:
From precompiled ZIPSpeaks for itself and applies to Win32 (i386-pc-mingw32) only. There is no real need to install ("fill up the registry") it, just extract the package into a new folder and run the applications from there. From sourceThe second way is to compile from source. It is for those who want to keep it in a single directory. However, if you intend to install it system-wide after compilation, I still point to the RPM specfile.
Extract the source tree and run Makefile.GNU. (You may add any GNU make relevant flags, like -j2.) If everything went well, ACCDB, its back-ends, system programs and C-spark will be compiled, lying in the current directory (the root of the Vitalnix tree). Note that ".", the current directory, is tried first for all libraries (this is the default under Win32 anyway), so if you happen to run any of the utilities from a directory which has a different, say, libaccdb.so.0.0, that one would be used instead. /etc, /usr/local/etc and . as search paths for configuration files are hardcoded into the programs. There is no install target in the Makefile to encourage the use of some database (like RPM, but you can use any other too) to track what files are installed. This is because a new version's source tree might have different uninstall target files, and it is unlikely that the old source tree will be kept that long. With RPM specfileThe third method, is to compile from source using the spec file for RPM. It is better than method #3 (source tree), as RPM will keep track of what files were installed. That info would be lost when using gmake's install. You will also be interested in this one when there is no precompiled RPM for your architecture and/or target OS. Especially because it combines the best of both worlds: machine-dependent flags and optimizations (will require adjustments of Makefile or specfile) and file tracking.
You can then install the RPM found in $RPMBUILD_PATH/RPMS/%arch/. For SuSE, this would be /usr/src/packages, for RedHat with /usr/src/redhat, other distributinos may offer it in another directory. From Source RPMI do not hand out any source RPMs, but should you run across one, you can use:
Various flags
You can pass DEBUG=1 to gmake to enable debugging support for GDB. (Note: The Makefiles in CVS have DEBUG set to 1, the released packages DO NOT.) As of Vitalnix v1.0.26.0, the make system has been silenced àla Linux v2.6.0. To get the usual make verbosity with printing all the commands that are executed, pass VERBOSE=1.
|