Example: You have the Linux 2.4.26 kernel source. Fact: You want to install the newest 2.4.xx kernel. Problem: You have GCC-3.4.0 installed. Solution: Temporarily install GCC-3.3.3. Here’s where relink comes in!
jpiszcz@p500:~$ cd /usr/src/linux-2.4.26
jpiszcz@p500:/usr/src/linux-2.4.26$ # needs gcc-3.3.3 or wont compile
jpiszcz@p500:/usr/src/linux-2.4.26$ gcc -v
Reading specs from /a/app/gcc-3.4.0/bin/../lib/gcc/i686-pc-linux-gnu/3.4.0/specs
Configured with: ./configure –prefix=/app/gcc-3.4.0
Thread model: posix
gcc version 3.4.0
jpiszcz@p500:/usr/src/linux-2.4.26$ mv /app/gcc-3.4.0 ~
jpiszcz@p500:/usr/src/linux-2.4.26$ relink
2480 link(s) removed
jpiszcz@p500:/usr/src/linux-2.4.26$ mv /appc/gcc-3.3.3 /app
jpiszcz@p500:/usr/src/linux-2.4.26$ relink
2200 link(s) installed
jpiszcz@p500:/usr/src/linux-2.4.26$ gcc -v
Reading specs from /vapp/bin/../lib/gcc-lib/i686-pc-linux-gnu/3.3.3/specs
Configured with: ./configure –prefix=/app/gcc-3.3.3
Thread model: posix
gcc version 3.3.3
jpiszcz@p500:/usr/src/linux-2.4.26$
You can now compile Kernel 2.4.26.
If you are interested in the history, benefits and purpose of using this tool as well as how to set it up and use it, please continue on.
What is relink?
Relink is an undiscovered treasure when it comes to package management.
How so?
With traditional package management, programs are installed all over
the system. For example installing a large application may put files in
/usr/include, /usr/lib, /usr/bin, /usr/sbin and the like. Some people might
say what about /usr/local? Yes, you can install programs into /usr/local, but
then it’s a mess, you do not know what versions of what you have installed!
Then, you have to rely on package management tools to determine what versions
of specific applications you have installed or you have to type the following
./program –version, but what if it is a library? Then you have to check the
headers or look in the *.la files which might help in determining the
version. With relink, all of your program are installed to the
$prefix/program-name-1.0.
What is the intent of relink?
Summarized from the manpage: relink is a utility designed to assist users
in managing packages with the normal application layout directory structure,
such as: application/bin, application/etc, application/lib, application/man.
It can be used to create a single directory path for tens to thousands of
applications.
In other words, you can have the latest and greatest applications in your
$HOME/app, instead of waiting for your system administrator install them
on the system for you!
The motivation for relink was inspired by two primary needs
1] The ability to organize and install software packages easily without
root access.
2] The ability to build applications and interrelated libraries
one time and then to share these between systems easily.
Some applications may take hours to build and install
due to dependencies and libraries required. relink
allows you do this one time for multiple machines.
Relink is probably of most interest to those who constantly want to
use the latest version of tools or applications or individuals
that must support moving applications between many systems.
If you are currently satisfied with your existing package
management system, rpm, pkgadd, depot, etc., relink may not
be of interest. However if you desire non root flexibility
and understanding where every file is without searching
relink may be of value.
Benefits of using relink
1] Full control of all of your packages.
2] Easy to backup.
3] Reduce risk of exploits (if relink user != root, which is recomended).
Explanation: Some source packages have become trojaned in the past and may be able to do further damage if the user running make install as root.
Backing up your applications
A nice thing to do is build all of your applications based upon other
libraries and applications that exist in your /app directory structure.
Why is this?
Because then the applications become portable (as long as glibc) is
the same version or greater on the other machine.
The thing I like most about relink is the ease of use it provides when
backing up all of my programs.
With a traditional package management system, some people might say:
“But oh, you can keep the rpms,tgz,deb.”
Well that may be true, however with relink you keep the entire directory
structure and the preferences you have for each application!
Example: /app/openssh-3.8.1p1/etc/sshd_config
I can untar my a.tar on another machine and setup the paths and voila
I have a complete working system again with all my applications and
tools. Without relink, I would be forced to backup my /usr partition
filled with all sorts of files intermingled with one another, which I
might add is not very useful when attempting to restore one’s system!
So how would I find the version of nmap that is installed using the following package management systems as shown below?
There are many package managers for Linux, some of the most popular
include the following:
1] Debian Package [tool: dpkg] ex: program.deb2] RedHat Package Manager [tool: rpm] ex: program.rpm
3] Slackware Package [tool: installpkg/removepkg/etc] ex: program.tgz
For Debian: dpkg -l | grep nmap
For RedHat: rpm -qa | grep nmap
For Slackware: ls -l /var/log/packages/nmap*
How would I find out which version of nmap was installed if I had used relink?
$ ls -ld /app/nmap-*
drwxr-xr-x 5 jpiszcz wheel 4.0K Jan 19 04:45 /app/nmap-3.50/
Why compile programs from source?
Example: Slackware 9.1 is my favorite distribution. However it has a serious
flaw, I launch gaim and try to connect to MSN, then what happens?
It says GAIM is not linked with the SSL libraries. Due to problems
similar to this I decided to start compiling almost everything I run
in late 1996 and control applications I install with relink.
Example: It has simplified my life and helped me organize the applications
I install. It also makes backups very easy and I will discuss this
in a moment.
Example: Distributions often lag behind when a new version of software is
released, perhaps your distribution does not have a package for
OpenSSL yet and you have to run an OpenSSH server for users, if you
do not want to risk getting compromised by the latest exploit
affecting up to OpenSSL 0.9.7c, then you need to upgrade. Using
relink provides a flexible means of doing this.
Why not use Gentoo/Lunar/Onebase/ROCK/Sorcerer/SourceMage or other source based distribution?
One word, control. Using automated package management might be a good thing
for some people, but I prefer to have complete control of my system and how
I compile each individual application. I also have found no distribution
that does what relink does by installing applications like the following
example: /app/program-1.0/{bin,etc,man,lib,sbin}.
Why use relink?
In my opinion, it is the best package management tool I have ever used.
I have been using it since 1996. It only requires Perl 5.6 on the
target system to run. I have personally tested it on a wide array of
Linux distributions and it has always worked no matter what distro I
was using. It also has been tested on Solaris 2.6 – 2.9.
Opinion #1: What is wrong with dpkg? Not much, however you still do not have
control over how your programs are created or what features they
contain.Opinion #2: What is wrong with rpm? RPM is a complete nightmare as most of us
know. Below is an example:Say you want to install program.rpm.
This is what often happens when you try to install an RPM.
# rpm –install program.rpm
program.rpm: depends on this.rpm that.rpm other.rpm
# rpm –install this.rpm that.rpm other.rpm
other.rpm: depends on this2.rpm that2.rpm more.rpm
# rpm –install this.rpm this2.rpm that.rpm that2.rpm other.rpm more.rpm
# rpm –install program.rpm
# program &
program: error __symbol_xyz_not_foundThis also made me literally sick of RPM, desperately looking for
another solution.Opinion #3: What is wrong with tgz? Not much, however you still do not have
control over how your programs are created or what features they
contain. In addition to that, there is no dependency checking,
which is a blessing for advanced users but may cause problems
for novice users.
Ok, so what are the requirements for relink?
The only requirement to run relink is Perl 5.6 or higher.
It looks cool, but how do I install relink?
The man page provides useful information on how to install relink, however
many of us like a tutorial or HOWTO walking us through the install process.
You can install relink in any prefix you desire.
For example: /app, $HOME/app, $HOME/myprograms, $HOME/your_choice
I have a freshly installed Slackware 9.1 system specifically for the purpose
of demonstrating how to install relink.
In my demonstration I will use /app (/a/app) as my prefix for installing
applications and the user jpiszcz as the owner the /a directory.
Step 01: Download relink
root@jpt2:~# wget http://aleron.dl.sourceforge.net/sourceforge/relink/relink-1.71.tar.gz
=> `relink-1.71.tar.gz’
Resolving aleron.dl.sourceforge.net… 204.157.3.229
Connecting to aleron.dl.sourceforge.net[204.157.3.229]:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 33,925 [application/x-gzip]100%[====================================>] 33,925 91.77K/s
22:48:11 (91.70 KB/s) – `relink-1.71.tar.gz’ saved [33925/33925]
root@jpt2:~#
Step 02: Decompress the package
root@jpt2:~# tar zxvf relink-1.71.tar.gz
relink/
relink/bin/
relink/bin/conf
relink/bin/relink
relink/doc/
relink/doc/relink.pdf
relink/doc/relink.txt
relink/doc/relink.ps
relink/doc/relink.html
relink/man/
relink/man/man1/
relink/man/man1/relink.1
root@jpt2:~#
Step 03: Setup your directory structure
root@jpt2:~# mkdir /a # this is the base directory.
root@jpt2:~# mkdir /a/app # this is where the programs are stored.
root@jpt2:~# mkdir /a/vapp # this is where the symlinks are stored
root@jpt2:~# ln -s /a/app /app # this is for convenience
root@jpt2:~# ln -s /a/vapp /vapp # this is used for your $PATH variables.
root@jpt2:~# chown jpiszcz:users -R /a
root@jpt2:~#
The last line allows jpiszcz:users to be the owner of /a, this is a good idea
for a single user system and more secure then running make install as root.
For some installations, creating a ‘relink’ user for the sole purpose of
installing and maintaining packages is recomended.
Step 04: Setup your PATHs
You may place the path wherever you choose, however I prefer to put them
in /etc/profile (Slackware) or /etc/bashrc (RedHat).
Add the following entries to the appropriate file.
#########################################################
# UNIX SYSTEM PATHS
#########################################################
# set the path
export PATH=/vapp/bin:/vapp/sbin:$PATH
# set the manpath
export MANPATH=/vapp/man:$MANPATH
# set the library path
export LD_LIBRARY_PATH=/vapp/lib:$LD_LIBRARY_PATH########################################################
# GCC COMPILER PATHS
########################################################
# set the c_include_path for gcc so when you compile programs
# it will search the headers in /vapp/include
export C_INCLUDE_PATH=/vapp/include:$C_INCLUDE_PATH
# the same but for C++ headers
export CPLUS_INCLUDE_PATH=$C_INCLUDE_PATH
# the same but for libraries
export LIBRARY_PATH=/vapp/lib:$LIBRARY_PATH########################################################
# The following may be optional or not depending on
# whether or not you use GNOME or wish to install various
# gnome system programs or libraries into /app.
########################################################
export ACLOCAL_FLAGS=”-I /vapp/share/aclocal -I /usr/share/aclocal”
export GNOME_PATH=”/vapp”
export PKG_CONFIG_PATH=”/vapp/lib/pkgconfig:/usr/lib/pkgconfig”
export QTDIR=”/app/qt-3.3.1″########################################################
# The following is highly recommended:
########################################################
To make sure the system knows about the new libraries, you should also add
the following line into /etc/ld.so.conf: /vapp/lib and run /sbin/ldconfig
afterwards. This ensures that the system knows where the libraries are and
in addition, OpenBSD’s OpenSSH secure ftp (sftp) daemon requires that this
step be done or else it will not be able to locate the paths for openssl
if you only have openssl in your /app.
root@jpt2:~# cat /etc/ld.so.conf
/vapp/lib
/usr/local/lib
/usr/X11R6/lib
/usr/i486-slackware-linux/lib
/opt/kde/lib
/usr/lib/qt/lib
/lib
root@jpt2:~# ldconfig
root@jpt2:~#
Step 05: Check your PATHs
After you have added the PATHs into /etc/profile or /etc/bashrc:
root@jpt2:~# grep . /etc/profile | tail -n 25
# set the path
export PATH=/vapp/bin:/vapp/sbin:$PATH
# set the manpath
export MANPATH=/vapp/man:$MANPATH
# set the library path
export LD_LIBRARY_PATH=/vapp/lib:$LD_LIBRARY_PATH
########################################################
# GCC COMPILER PATHS
########################################################
# set the c_include_path for gcc so when you compile programs
# it will search the headers in /vapp/include
export C_INCLUDE_PATH=/vapp/include:$C_INCLUDE_PATH
# the same but for C++ headers
export CPLUS_INCLUDE_PATH=$C_INCLUDE_PATH
# the same but for libraries
export LIBRARY_PATH=/vapp/lib:$LIBRARY_PATH
########################################################
# The following may be optional or not depending on
# whether or not you use GNOME or wish to install various
# gnome system programs or libraries into /app.
########################################################
export ACLOCAL_FLAGS=”-I /vapp/share/aclocal -I /usr/share/aclocal”
export GNOME_PATH=”/vapp”
export PKG_CONFIG_PATH=”/vapp/lib/pkgconfig:/usr/lib/pkgconfig”
export QTDIR=”/app/qt-3.3.1″
root@jpt2:~#
Then source the new file your environment is aware of the new paths.
root@jpt2:~# . /etc/profileTo check that your settings worked properly, simply check a PATH.
root@jpt2:~# echo $PATH
/vapp/bin:/vapp/sbin:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:
/bin:/usr/X11R6/bin:/usr/games:/opt/www/htdig/bin:/usr/lib/java/bin:
/usr/lib/java/jre/bin:/opt/kde/bin:/usr/lib/qt/bin:/usr/share/texmf/bin
root@jpt2:~#
Step 06: Move relink into /app and set permissions to the user that you will be running relink as
root@jpt2:~# mv relink /app
root@jpt2:~# chown jpiszcz:users -R /a
Step 07: Run relink to set the paths and initialize the database
Note the user change: I am now user ‘jpiszcz’
jpiszcz@jpt2:~$ /app/relink/bin/relinkRELINK_ERROR>> $HOME/.relinkrc does not exist.
RELINK_ERROR>> try relink –setupoptions, use only one option at a time
-h|-help|–help : this menu
-i|-init|–init : initialize relink system
-k|-keep|–keep : keep files generated in /tmp, for debug
-s|-setup|–setup : setup directories
-v|-verbose|–verbose : verbose output of progress
-V|-version|–version : output version informationjpiszcz@jpt2:~$ /app/relink/bin/relink -s
Enter Application Directory (e.g. /a/app): /a/app
Run relink again
jpiszcz@jpt2:~$ relink
-su: relink: command not found
jpiszcz@jpt2:~$ # There is a small bug in the installation as you can see here.
jpiszcz@jpt2:~$ # To remedy:
jpiszcz@jpt2:~$ /app/relink/bin/relink -i
APPDIR: /a/app
RELINK>> Delete all files in current directory
RELINK>> DIRECTORY: /a/vappvapp
RELINK>> CTRL-C to abort, ‘Y’ to continue: Y
Removing all vapp symbolic link files
/a/vapp
Removing rdb filesExecuting relink: [/a/app/relink/bin/relink] diff: /a/rdb/rdb.dat: No such file or directory
diff: /a/rdb/rdb.dat: No such file or directory
/bin/cp: cannot stat `./rdb/rdb.dat’: No such file or directory
jpiszcz@jpt2:~$ # This is the second and last but during installation.
jpiszcz@jpt2:~$ # To remedy:
jpiszcz@jpt2:~$ /app/relink/bin/relink -i
APPDIR: /a/app
RELINK>> Delete all files in current directory
RELINK>> DIRECTORY: /a/vapprdb.dat
RELINK>> CTRL-C to abort, ‘Y’ to continue: Y
Removing all vapp symbolic link files
/a/rdb
rdb.dat
Removing rdb filesExecuting relink: [/a/app/relink/bin/relink] 14 link(s) installed
jpiszcz@jpt2:~$
Congratulations, you have successfully installed relink!
Ok that’s great I have installed relink, now how do I use it?
In the proceeding text I will show three things
1] Install a library into /app.
2] Install a program that depends on the library installed in /app.
2] Remove a program.
3] Upgrade a program.
Example: Install OpenSSH and OpenSSL
Step 01: Download the OpenSSL and OpenSSH source tarballs
jpiszcz@jpt2:~$ wget ftp://ftp.openssl.org/source/openssl-0.9.7d.tar.gz
–23:20:12– ftp://ftp.openssl.org/source/openssl-0.9.7d.tar.gz
=> `openssl-0.9.7d.tar.gz’
Resolving ftp.openssl.org… 195.27.176.155
Connecting to ftp.openssl.org[195.27.176.155]:21… connected.
Logging in as anonymous … Logged in!
==> SYST … done. ==> PWD … done.
==> TYPE I … done. ==> CWD /source … done.
==> PORT … done. ==> RETR openssl-0.9.7d.tar.gz … done.
Length: 2,798,433 (unauthoritative)100%[====================================>] 2,798,433 90.19K/s ETA 00:00
23:20:45 (86.64 KB/s) – `openssl-0.9.7d.tar.gz’ saved [2798433]
jpiszcz@jpt2:~$
jpiszcz@jpt2:~$ wget ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-3.8.1p1.tar.gz–23:23:05– ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-3.8.1p1.tar.gz
=> `openssh-3.8.1p1.tar.gz’
Resolving ftp.openbsd.org… 129.128.5.191
Connecting to ftp.openbsd.org[129.128.5.191]:21… connected.
Logging in as anonymous … Logged in!
==> SYST … done. ==> PWD … done.
==> TYPE I … done. ==> CWD /pub/OpenBSD/OpenSSH/portable … done.
==> PORT … done. ==> RETR openssh-3.8.1p1.tar.gz … done.
Length: 817,932 (unauthoritative)100%[====================================>] 817,932 23.20K/s ETA 00:00
23:23:29 (42.98 KB/s) – `openssh-3.8.1p1.tar.gz’ saved [817932]
jpiszcz@jpt2:~$
Step 02: Decompress the tarballs
jpiszcz@jpt2:~$ tar zxf openssl-0.9.7d.tar.gz
jpiszcz@jpt2:~$ tar zxf openssh-3.8.1p1.tar.gz
jpiszcz@jpt2:~$
Step 03: Run ./config
For OpenSSL, it has its own ‘config’ script, earlier versions seemed to have
supported a prefix option, but the newest does not.
jpiszcz@jpt2:~$ cd openssl-0.9.7d
jpiszcz@jpt2:~/openssl-0.9.7d$ ./config
Operating system: i686-whatever-linux2
Configuring for linux-pentium
.. various tests here ..
jpiszcz@jpt2:~/openssl-0.9.7d$
Step 03: Edit Makefile
jpiszcz@jpt2:~$ cd openssl-0.9.7d
jpiszcz@jpt2:~/openssl-0.9.7d$ vi Makefile
The part you need to change is here:
# INSTALL_PREFIX is for package builders so that they can configure
# for, say, /usr/ and yet have everything installed to /tmp/somedir/usr/.
# Normally it is left empty.
INSTALL_PREFIX=
INSTALLTOP=/usr/local/sslChange INSTALL_PREFIX= to INSTALL_PREFIX=/app
and
INSTALLTOP= to INSTALLTOP=/openssl-0.9.7dSo when done, it should look like this:
# INSTALL_PREFIX is for package builders so that they can configure
# for, say, /usr/ and yet have everything installed to /tmp/somedir/usr/.
# Normally it is left empty.
INSTALL_PREFIX=/app
INSTALLTOP=/openssl-0.9.7d
Step 04: Run make to compile the program
jpiszcz@jpt2:~/openssl-0.9.7d$ /usr/bin/time make -j2
Some users may be curious to why I used the -j2 option (especially when I only
have a single CPU in my machine), running make with no -j2 option is perfectly
fine. Instead of one thread for compiling, running make with the -j2 (jobs: 2)
option, it runs two jobs simultaneously. Therefore make -j2 usually results
in faster compilation times depending upon what you are compiling.
Some may also be curious as to why this is? Well that has to do with the
Linux process scheduler and that is a topic for another day.
Step 05: Run make install
jpiszcz@jpt2:~/openssl-0.9.7d$ make install
.. various installer information here ..
make[1]: Entering directory `/home/jpiszcz/openssl-0.9.7d/tools’
make[1]: Leaving directory `/home/jpiszcz/openssl-0.9.7d/tools’
installing libcrypto.a
installing libssl.a
cp openssl.pc /app/openssl-0.9.7d/lib/pkgconfig
chmod 644 /app/openssl-0.9.7d/lib/pkgconfig/openssl.pc
jpiszcz@jpt2:~/openssl-0.9.7d$
Step 06: Shared or Static?
This is a also a discussion for another time, however most programs in Linux
are built using shared libraries as it offers many benefits over building them
statically, please Google search for more information about why this is so.
We want a shared OpenSSL library!
By default, OpenSSL 0.9.7d does not compile or install a shared library.
To remedy this problem:
jpiszcz@jpt2:~/openssl-0.9.7d$ make build-shared
+ rm -f libcrypto.so.0
+ rm -f libcrypto.so
+ rm -f libcrypto.so.0.9.7
+ rm -f libssl.so.0
+ rm -f libssl.so
+ rm -f libssl.so.0.9.7
libs=’-L. ‘; for i in crypto ssl; do \
if [ “crypto ssl” = “ssl” -a -n “” ]; then \
libs=” $libs”; \
fi; \
( set -x; gcc \
-shared -o lib$i.so.0.9.7 \
-Wl,-soname=lib$i.so.0.9.7 \
-Wl,-Bsymbolic \
-Wl,–whole-archive lib$i.a \
-Wl,–no-whole-archive $libs -ldl -lc ) || exit 1; \
libs=”-l$i $libs”; \
done
+ gcc -shared -o libcrypto.so.0.9.7 -Wl,-soname=libcrypto.so.0.9.7 -Wl,-Bsymbolic \
-Wl,–whole-archive libcrypto.a -Wl,–no-whole-archive -L. -ldl -lc
+ gcc -shared -o libssl.so.0.9.7 -Wl,-soname=libssl.so.0.9.7 -Wl,-Bsymbolic -Wl, \
–whole-archive libssl.a -Wl,–no-whole-archive -lcrypto -L. -ldl -lc
+ rm -f libcrypto.so.0
+ ln -s libcrypto.so.0.9.7 libcrypto.so.0
+ rm -f libcrypto.so
+ ln -s libcrypto.so.0 libcrypto.so
+ rm -f libssl.so.0
+ ln -s libssl.so.0.9.7 libssl.so.0
+ rm -f libssl.so
+ ln -s libssl.so.0 libssl.so
jpiszcz@jpt2:~/openssl-0.9.7d$
Step 07: Install the shared library
If you thought make install will do it, you will be mistaken.
Simply move the libraries to the app/lib directory and relink!
jpiszcz@jpt2:~/openssl-0.9.7d$ mv *.so* /app/openssl-0.9.7d/lib
jpiszcz@jpt2:~/openssl-0.9.7d$ relink # I had previously relinked
6 link(s) installed # before moving the libraries.
jpiszcz@jpt2:~/openssl-0.9.7d$ # This only the library
# related files are relinked
# at this time.
Congratulations, you have successfully built and installed OpenSSL
with shared libraries! Now for OpenSSH…
Step 08: Installing OpenSSH
In recent versions, a user (sshd) by default is required by OpenSSH.
Slackware 9.1 by default has this user added, if this user is not
added, you must add it.
jpiszcz@jpt2:~/openssl-0.9.7d$ grep -i sshd /etc/passwd
sshd:x:33:33:sshd:/:
jpiszcz@jpt2:~/openssl-0.9.7d$
Next, view the available options to compile OpenSSH.
jpiszcz@jpt2:~/openssl-0.9.7d$ cd ~/openssh-3.8.1p1
jpiszcz@jpt2:~/openssh-3.8.1p1$ ./configure –help
`configure’ configures this package to adapt to many kinds of systems.Usage: ./configure [OPTION]… [VAR=VALUE]…
To assign environment variables (e.g., CC, CFLAGS…), specify them as
VAR=VALUE. See below for descriptions of some of the useful variables.Defaults for the options are specified in brackets.
Configuration:
-h, –help display this help and exit
–help=short display options specific to this package
–help=recursive display the short help of all the included packages
-V, –version display version information and exit
-q, –quiet, –silent do not print `checking…’ messages
–cache-file=FILE cache test results in FILE [disabled] -C, –config-cache alias for `–cache-file=config.cache’
-n, –no-create do not create output files
–srcdir=DIR find the sources in DIR [configure dir or `..’]Installation directories:
–prefix=PREFIX install architecture-independent files in PREFIX
[/usr/local] –exec-prefix=EPREFIX install architecture-dependent files in EPREFIX
[PREFIX]By default, `make install’ will install all the files in
`/usr/local/bin’, `/usr/local/lib’ etc. You can specify
an installation prefix other than `/usr/local’ using `–prefix’,
for instance `–prefix=$HOME’.For better control, use the options below.
Fine tuning of the installation directories:
–bindir=DIR user executables [EPREFIX/bin] –sbindir=DIR system admin executables [EPREFIX/sbin] –libexecdir=DIR program executables [EPREFIX/libexec] –datadir=DIR read-only architecture-independent data [PREFIX/share] –sysconfdir=DIR read-only single-machine data [PREFIX/etc] –sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com] –localstatedir=DIR modifiable single-machine data [PREFIX/var] –libdir=DIR object code libraries [EPREFIX/lib] –includedir=DIR C header files [PREFIX/include] –oldincludedir=DIR C header files for non-gcc [/usr/include] –infodir=DIR info documentation [PREFIX/info] –mandir=DIR man documentation [PREFIX/man]System types:
–build=BUILD configure for building on BUILD [guessed] –host=HOST build programs to run on HOST [BUILD]Optional Features:
–disable-FEATURE do not include FEATURE (same as –enable-FEATURE=no)
–enable-FEATURE[=ARG] include FEATURE [ARG=yes] –disable-largefile omit support for large files
–disable-strip Disable calling strip(1) on install
–disable-etc-default-login Disable using PATH from /etc/default/login no
–disable-lastlog disable use of lastlog even if detected no
–disable-utmp disable use of utmp even if detected no
–disable-utmpx disable use of utmpx even if detected no
–disable-wtmp disable use of wtmp even if detected no
–disable-wtmpx disable use of wtmpx even if detected no
–disable-libutil disable use of libutil (login() etc.) no
–disable-pututline disable use of pututline() etc. (uwtmp) no
–disable-pututxline disable use of pututxline() etc. (uwtmpx) noOptional Packages:
–with-PACKAGE[=ARG] use PACKAGE [ARG=yes] –without-PACKAGE do not use PACKAGE (same as –with-PACKAGE=no)
–without-rpath Disable auto-added -R linker paths
–with-osfsia Enable Digital Unix SIA
–with-cflags Specify additional flags to pass to compiler
–with-cppflags Specify additional flags to pass to preprocessor
–with-ldflags Specify additional flags to pass to linker
–with-libs Specify additional libraries to link with
–with-zlib=PATH Use zlib in PATH
–without-zlib-version-check Disable zlib version check
–with-skey[=PATH] Enable S/Key support
(optionally in PATH)
–with-tcp-wrappers[=PATH] Enable tcpwrappers support
(optionally in PATH)
–with-pam Enable PAM support
–with-ssl-dir=PATH Specify path to OpenSSL installation
–with-rand-helper Use subprocess to gather strong randomness
–with-prngd-port=PORT read entropy from PRNGD/EGD TCP localhost:PORT
–with-prngd-socket=FILE read entropy from PRNGD/EGD socket FILE (default=/var/run/egd-pool)
–with-entropy-timeout Specify entropy gathering command timeout (msec)
–with-privsep-user=user Specify non-privileged user for privilege separation
–with-sectok Enable smartcard support using libsectok
–with-opensc=PFX Enable smartcard support using OpenSC
–with-kerberos5=PATH Enable Kerberos 5 support
–with-privsep-path=xxx Path for privilege separation chroot (default=/var/empty)
–with-xauth=PATH Specify path to xauth program
–with-mantype=man|cat|doc Set man page type
–with-md5-passwords Enable use of MD5 passwords
–without-shadow Disable shadow password support
–with-ipaddr-display Use ip address instead of hostname in \$DISPLAY
–with-default-path= Specify default \$PATH environment for server
–with-superuser-path= Specify different path for super-user
–with-4in6 Check for and convert IPv4 in IPv6 mapped addresses
–with-bsd-auth Enable BSD auth support
–with-pid-dir=PATH Specify location of ssh.pid file
–with-lastlog=FILE|DIR specify lastlog location common locationsSome influential environment variables:
CC C compiler command
CFLAGS C compiler flags
LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a
nonstandard directory <lib dir>
CPPFLAGS C/C++ preprocessor flags, e.g. -I<include dir> if you have
headers in a nonstandard directory <include dir>
CPP C preprocessorUse these variables to override the choices made by `configure’ or to help
it to find libraries and programs with nonstandard names/locations.jpiszcz@jpt2:~/openssh-3.8.1p1$
Step 09: Configure the OpenSSH build
jpiszcz@jpt2:~/openssh-3.8.1p1$ ./configure –prefix=/app/openssh-3.8.1p1
.. configure status ..
Important output from configure to pay attention to:
checking OpenSSL header version… 90704f (OpenSSL 0.9.7d 17 Mar 2004)
checking OpenSSL library version… 90704f (OpenSSL 0.9.7d 17 Mar 2004)
checking whether OpenSSL’s headers match the library… yes
checking for crypt in -lcrypt… yes
checking whether OpenSSL’s PRNG is internally seeded… yesIf this does not detect your version of OpenSSL, some programs
may need –with-ssl-dir=PATH Specify path to OpenSSL installationWithout the –with-ssl-dir option specified, we get:
Preprocessor flags:
Linker flags:
This shows that it is building off of your distribution’s inclusion
of OpenSSL (somewhere in /usr).
In the previous text, I described the GCC environmental variables, this
allows configure to find 70-90% of your applications in /app without
having to use such an option (–with-ssl-dir). However, for some
applications, it may be necessary to tell them explicitly where the
appropriate application or library is located.
For example: ./configure –prefix=/app/openssh-3.8.1p1 \
–with-ssl-dir=/app/openssl-0.9.7d
Therefore the –with-ssl-dir is required for OpenSSH if you want it
to compile off of the version that you have just installed in /app.
Not all programs require this, another solution is to remove all
duplicate software on your system and just keep everything in /app.
The ending (most important output is listed):
configure: creating ./config.status
config.status: creating Makefile
config.status: creating openbsd-compat/Makefile
config.status: creating scard/Makefile
config.status: creating ssh_prng_cmds
config.status: creating config.h
config.status: config.h is unchangedOpenSSH has been configured with the following options:
User binaries: /app/openssh-3.8.1p1/bin
System binaries: /app/openssh-3.8.1p1/sbin
Configuration files: /app/openssh-3.8.1p1/etc
Askpass program: /app/openssh-3.8.1p1/libexec/ssh-askpass
Manual pages: /app/openssh-3.8.1p1/man/manX
PID file: /var/run
Privilege separation chroot path: /var/empty
sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin:/app/openssh-3.8.1p1/bin
Manpage format: doc
PAM support: no
KerberosV support: no
Smartcard support: no
S/KEY support: no
TCP Wrappers support: no
MD5 password support: no
IP address in $DISPLAY hack: no
Translate v4 in v6 hack: yes
BSD Auth support: no
Random number source: OpenSSL internal ONLYHost: i686-pc-linux-gnu
Compiler: gcc
Compiler flags: -g -O2 -Wall -Wpointer-arith -Wno-uninitialized
Preprocessor flags: -I/app/openssl-0.9.7d/include
Linker flags: -L/app/openssl-0.9.7d/lib
Libraries: -lresolv -lcrypto -lutil -lz -lnsl -lcryptjpiszcz@jpt2:~/openssh-3.8.1p1$
As you can now see, it will build off of the correct library.
Step 10 – Install OpenSSH
gcc -o ssh-add ssh-add.o -L. -Lopenbsd-compat/ -L/app/openssl-0.9.7d/lib -lssh -lopenbsd-compat -lresolv -lcrypto -lutil -lz -lnsl -lcrypt
gcc -o ssh-keygen ssh-keygen.o -L. -Lopenbsd-compat/ -L/app/openssl-0.9.7d/lib -lssh -lopenbsd-compat -lresolv -lcrypto -lutil -lz -lnsl -lcrypt
gcc -o ssh-keyscan ssh-keyscan.o -L. -Lopenbsd-compat/ -L/app/openssl-0.9.7d/lib -lssh -lopenbsd-compat -lssh -lresolv -lcrypto -lutil -lz -lnsl -lcrypt
gcc -o ssh-keysign ssh-keysign.o readconf.o -L. -Lopenbsd-compat/ -L/app/openssl-0.9.7d/lib -lssh -lopenbsd-compat -lresolv -lcrypto -lutil -lz -lnsl -lcrypt
gcc -o ssh-agent ssh-agent.o -L. -Lopenbsd-compat/ -L/app/openssl-0.9.7d/lib -lssh -lopenbsd-compat -lresolv -lcrypto -lutil -lz -lnsl -lcrypt
gcc -o scp scp.o progressmeter.o -L. -Lopenbsd-compat/ -L/app/openssl-0.9.7d/lib -lssh -lopenbsd-compat -lresolv -lcrypto -lutil -lz -lnsl -lcrypt
gcc -o ssh-rand-helper ssh-rand-helper.o -L. -Lopenbsd-compat/ -L/app/openssl-0.9.7d/lib -lssh -lopenbsd-compat -lresolv -lcrypto -lutil -lz -lnsl -lcrypt
gcc -o sftp-server sftp-server.o sftp-common.o -L. -Lopenbsd-compat/ -L/app/openssl-0.9.7d/lib -lssh -lopenbsd-compat -lresolv -lcrypto -lutil -lz -lnsl -lcrypt
gcc -o sftp progressmeter.o sftp.o sftp-client.o sftp-common.o sftp-glob.o -L. -Lopenbsd-compat/ -L/app/openssl-0.9.7d/lib -lssh -lopenbsd-compat -lresolv -lcrypto -lutil -lz -lnsl -lcrypt
jpiszcz@jpt2:~/openssh-3.8.1p1$ make install
.. installer information here ..
mkdir /app/openssh-3.8.1p1/etc
Generating public/private rsa1 key pair.
Your identification has been saved in /app/openssh-3.8.1p1/etc/ssh_host_key.
Your public key has been saved in /app/openssh-3.8.1p1/etc/ssh_host_key.pub.
The key fingerprint is:
35:57:5e:88:34:9f:96:32:4b:69:21:4a:f2:48:06:be jpiszcz@jpt2
Generating public/private dsa key pair.
Your identification has been saved in /app/openssh-3.8.1p1/etc/ssh_host_dsa_key.
Your public key has been saved in /app/openssh-3.8.1p1/etc/ssh_host_dsa_key.pub.
The key fingerprint is:
28:4f:27:7a:6d:46:6b:18:ef:2a:35:d4:61:6c:4a:94 jpiszcz@jpt2
Generating public/private rsa key pair.
Your identification has been saved in /app/openssh-3.8.1p1/etc/ssh_host_rsa_key.
Your public key has been saved in /app/openssh-3.8.1p1/etc/ssh_host_rsa_key.pub.
The key fingerprint is:
71:fd:be:27:73:1f:91:fa:f3:a1:f7:a6:9c:5f:e3:b4 jpiszcz@jpt2
/app/openssh-3.8.1p1/sbin/sshd -t -f /app/openssh-3.8.1p1/etc/sshd_config
jpiszcz@jpt2:~/openssh-3.8.1p1$
You may get an error about /var/empty, if you do, this is how you fix it:
root@jpt2:~# chmod 700 /var/empty
root@jpt2:~# chown root:root /var/empty
NOTE: You *MUST* fix the error about /var/empty if you get one or the ssh daemon
will not work properly.
Step 12 – Run relink!
jpiszcz@jpt2:~/openssh-3.8.1p1$ relink
44 link(s) installed
jpiszcz@jpt2:~/openssh-3.8.1p1$
Step 12 – Explore the directory structure
jpiszcz@jpt2:/app/openssh-3.8.1p1$ ls bin/
scp* sftp* slogin@ ssh* ssh-add* ssh-agent* ssh-keygen* ssh-keyscan*
jpiszcz@jpt2:/app/openssh-3.8.1p1$ ls etc/
moduli ssh_host_dsa_key.pub ssh_host_rsa_key
ssh_config ssh_host_key ssh_host_rsa_key.pub
ssh_host_dsa_key ssh_host_key.pub sshd_config
jpiszcz@jpt2:/app/openssh-3.8.1p1$ ls libexec/
sftp-server* ssh-keysign*
jpiszcz@jpt2:/app/openssh-3.8.1p1$ ls man/
man1/ man5/ man8/
jpiszcz@jpt2:/app/openssh-3.8.1p1$ ls sbin/
sshd*
jpiszcz@jpt2:/app/openssh-3.8.1p1$ ls share/
Ssh.bin
jpiszcz@jpt2:/app/openssh-3.8.1p1$
jpiszcz@jpt2:/app/openssh-3.8.1p1$ du -sh $PWD
1.4M /app/openssh-3.8.1p1
jpiszcz@jpt2:/app/openssh-3.8.1p1$
Step 13 – Make sure ssh/sshd are using the new library
jpiszcz@jpt2:/app/openssh-3.8.1p1$ ldd `which ssh`
libresolv.so.2 => /lib/libresolv.so.2 (0x4002c000)
* libcrypto.so.0.9.7 => /vapp/lib/libcrypto.so.0.9.7 (0x4003e000)
libutil.so.1 => /lib/libutil.so.1 (0x40132000)
libz.so.1 => /usr/lib/libz.so.1 (0x40135000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40143000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40158000)
libc.so.6 => /lib/libc.so.6 (0x40185000)
libdl.so.2 => /lib/libdl.so.2 (0x402b4000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
jpiszcz@jpt2:/app/openssh-3.8.1p1$ ldd `which sshd`
libresolv.so.2 => /lib/libresolv.so.2 (0x4002c000)
* libcrypto.so.0.9.7 => /vapp/lib/libcrypto.so.0.9.7 (0x4003e000)
libutil.so.1 => /lib/libutil.so.1 (0x40132000)
libz.so.1 => /usr/lib/libz.so.1 (0x40135000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40143000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40158000)
libc.so.6 => /lib/libc.so.6 (0x40185000)
libdl.so.2 => /lib/libdl.so.2 (0x402b4000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
jpiszcz@jpt2:/app/openssh-3.8.1p1$ ls -l /vapp/lib/libcrypto.so.0.9.7
lrwxrwxrwx 1 jpiszcz users 47 May 27 00:10 /vapp/lib/libcrypto.so.0.9.7 -> \
../../app/openssl-0.9.7d/lib/libcrypto.so.0.9.7*
jpiszcz@jpt2:/app/openssh-3.8.1p1$jpiszcz@jpt2:~$ ssh -V
OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004
jpiszcz@jpt2:~$
You have successfully installed the latest versions of OpenSSH and OpenSSL (as of 05/27/2004)!
Step 14 – Setting up OpenSSH daemon
I’ve explained the installation of the client so I may as well
describe how to setup the daemon.
As you know, you can use OpenSSH daemon as a standalone daemon
or run from (x)inetd, in my examples I will show all three.
Example 1] Run as daemon.
In a startup script, simply type.
/vapp/bin/sshd &Example 2:] Run from inetd.
Add the following line to /etc/inetd.conf as root:
ssh stream tcp nowait root /vapp/sbin/sshd sshd -i
As root type: killall -HUP inetd
root@jpt2:~# vi /etc/inetd.conf
root@jpt2:~# killall -HUP inetd
root@jpt2:~#
Kill the old version of daemon running (preferably in a telnet session).
root@jpt2:~# killall -9 sshd
Connection to 192.168.0.101 closed by remote host.
Connection to 192.168.0.101 closed.
Please do not ask me why, but after you killall -9 sshd, you have to
killall -HUP inetd once more.
If you do not do this, you will get:
$ ssh -v 192.168.0.101
OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004
debug1: Reading configuration data /home/war/.ssh/config
debug1: Reading configuration data /app/openssh-3.8.1p1/etc/ssh_config
debug1: Connecting to 192.168.0.101 [192.168.0.101] port 22.
debug1: connect to address 192.168.0.101 port 22: Connection refused
ssh: connect to host 192.168.0.101 port 22: Connection refused
After killall -HUP inetd once more (mentioned above), then it works:
war@p500:~$ ssh -l jpiszcz -v 192.168.0.101
OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004
debug1: Reading configuration data /home/war/.ssh/config
debug1: Reading configuration data /app/openssh-3.8.1p1/etc/ssh_config
debug1: Connecting to 192.168.0.101 [192.168.0.101] port 22.
debug1: Connection established.
debug1: identity file /home/war/.ssh/identity type -1
debug1: identity file /home/war/.ssh/id_rsa type -1
debug1: identity file /home/war/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.8.1p1
debug1: match: OpenSSH_3.8.1p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 zlib
debug1: kex: client->server aes128-cbc hmac-md5 zlib
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host '192.168.0.101' is known and matches the RSA host key. debug1: Found key in /home/war/.ssh/known_hosts:1 debug1: ssh_rsa_verify: signature correct debug1: Enabling compression at level 6. debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: publickey debug1: Trying private key: /home/war/.ssh/identity debug1: Trying private key: /home/war/.ssh/id_rsa debug1: Trying private key: /home/war/.ssh/id_dsa debug1: Next authentication method: keyboard-interactive debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: password [email protected]'s password: debug1: Authentication succeeded (password). debug1: channel 0: new [client-session] debug1: Entering interactive session. Linux 2.4.22. jpiszcz@jpt2:~$
Step 15 – Making sure your sshd uses the latest OpenSSL
There are a few ways of accomplishing this.
1] Most simple, run it as a daemon (make sure to source bashrc/profile
beforehand).
2] Edit your boot scripts to use /vapp first (or source your bashrc/profile)
first before running inetd. Then your entire environment can encompass
/vapp and this will be searched/linked upon before anything else.
3] Remove old versions of OpenSSL on your system.
I personally choose number 3 to be absolutely sure.
root@jpt2:/var/log/packages# removepkg openssl-*Removing package /var/log/packages/openssl-0.9.7d-i486-1…
Removing files:
.. deleting files ..
Removing package /var/log/packages/openssl-solibs-0.9.7d-i486-1…
Removing files:
.. deleting files ..
Now when I try to login:
$ ssh -l jpiszcz -v 192.168.0.101
OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004
debug1: Reading configuration data /home/war/.ssh/config
debug1: Reading configuration data /app/openssh-3.8.1p1/etc/ssh_config
debug1: Connecting to 192.168.0.101 [192.168.0.101] port 22.
debug1: Connection established.
debug1: identity file /home/war/.ssh/identity type -1
debug1: identity file /home/war/.ssh/id_rsa type -1
debug1: identity file /home/war/.ssh/id_dsa type -1
debug1: ssh_exchange_identification: sshd: error while loading shared libraries: \
libcrypto.so.0.9.7: cannot open shared object file: No such file or directoryssh_exchange_identification: Connection closed by remote host
Ah hah! It was using the older OpenSSL!
To fix this, run ldconfig (update shared library paths) and then login.
jpiszcz@p500:~$ telnet 192.168.0.101
Trying 192.168.0.101…
Connected to 192.168.0.101.
Escape character is ‘^]’.jpt2 login: jpiszcz
Password:
Linux 2.4.22.
Last login: Thu May 27 00:50:44 -0400 2004 on pts/0 from p500.
No mail.
jpiszcz@jpt2:~$ su –
Password:
root@jpt2:~# ldconfig
root@jpt2:~# logout
jpiszcz@jpt2:~$ logout
Connection closed by foreign host.
jpiszcz@p500:~$ ssh -l jpiszcz -v 192.168.0.101
OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004
debug1: Reading configuration data /home/jpiszcz/.ssh/config
debug1: Reading configuration data /app/openssh-3.8.1p1/etc/ssh_config
debug1: Connecting to 192.168.0.101 [192.168.0.101] port 22.
debug1: Connection established.
debug1: identity file /home/jpiszcz/.ssh/identity type -1
debug1: identity file /home/jpiszcz/.ssh/id_rsa type -1
debug1: identity file /home/jpiszcz/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote softjpiszcze version OpenSSH_3.8.1p1
debug1: match: OpenSSH_3.8.1p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 zlib
debug1: kex: client->server aes128-cbc hmac-md5 zlib
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host '192.168.0.101' is known and matches the RSA host key. debug1: Found key in /home/jpiszcz/.ssh/known_hosts:1 debug1: ssh_rsa_verify: signature correct debug1: Enabling compression at level 6. debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: publickey debug1: Trying private key: /home/jpiszcz/.ssh/identity debug1: Trying private key: /home/jpiszcz/.ssh/id_rsa debug1: Trying private key: /home/jpiszcz/.ssh/id_dsa debug1: Next authentication method: keyboard-interactive debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: password [email protected]'s password: debug1: Authentication succeeded (password). debug1: channel 0: new [client-session] debug1: Entering interactive session. Last login: Thu May 27 00:52:31 2004 from p500 Linux 2.4.22. jpiszcz@jpt2:~$
Finally we have installed the newest version of OpenSSH with the
newest version of OpenSSL and we are 100% certain it is using the
newest version of OpenSSL as no other versions exist on the
system.
Removing an application
We are now on step two of the following list.
- Install a library into /app. (DONE)
- Install a program that depends on the library installed in /app. (DONE)
- Remove a program.
- Upgrade a program.
This clearly demonstrates the power of relink.
Say a new version of OpenSSH came out and you want to remove the one you
have installed.
jpiszcz@jpt2:~$ mv /app/openssh-3.8.1p1 .
jpiszcz@jpt2:~$ relink
44 link(s) removed
jpiszcz@jpt2:~$
Voila! It is uninstalled.
Upgrading a program
As it already may be self-evident, I will demonstrate upgrading a program
using relink as well as how to fix a possible bug if you encounter it.
For my example, I will be installing mtr 0.55 and then upgrade to 0.58.
jpiszcz@jpt2:~$ ls -l *bz2
-rw-r–r– 1 jpiszcz users 84896 May 27 01:07 mtr-0.55.tar.bz2
-rw-r–r– 1 jpiszcz users 82853 May 27 01:07 mtr-0.58.tar.bz2
jpiszcz@jpt2:~$ tar jxf mtr-0.55.tar.bz2 ; tar jxf mtr-0.58.tar.bz2
jpiszcz@jpt2:~$
A nice little script is including with relink called conf, this
sets up your ./configure –prefix=/app/program for you then
makes the program.
jpiszcz@jpt2:~/mtr-0.55$ confAutoconfigure for /app piszcz v1.0
pkgName: mtr-0.55
newDir: /app/mtr-0.55
./configure –prefix=/app/mtr-0.55
creating cache ./config.cache
checking for a BSD compatible install… /usr/bin/ginstall -c.. configure stuff here ..
.. make stuff here ..
gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 \
-I/usr/lib/glib/include -I/usr/X11R6/include -c curses.c
gcc -g -O2 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include \
-I/usr/X11R6/include -o mtr gtk.o curses.o mtr.o net.o dns.o \
raw.o split.o display.o report.o getopt.o getopt1.o select.o -lresolv -lm -lncurses -ltermcap \
-L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXext -lX11 -lm
make[2]: Leaving directory `/home/jpiszcz/mtr-0.55′
make[1]: Leaving directory `/home/jpiszcz/mtr-0.55′real 0m21.158s
user 0m18.610s
sys 0m1.040sif everything looks good: make install
jpiszcz@jpt2:~/mtr-0.55$
jpiszcz@jpt2:~/mtr-0.55$ make install
Making install in img
make[1]: Entering directory `/home/jpiszcz/mtr-0.55/img’
make[2]: Entering directory `/home/jpiszcz/mtr-0.55/img’
make[2]: Nothing to be done for `install-exec-am’.
make[2]: Nothing to be done for `install-data-am’.
make[2]: Leaving directory `/home/jpiszcz/mtr-0.55/img’
make[1]: Leaving directory `/home/jpiszcz/mtr-0.55/img’
make[1]: Entering directory `/home/jpiszcz/mtr-0.55′
make[2]: Entering directory `/home/jpiszcz/mtr-0.55′
/bin/sh ./mkinstalldirs /app/mtr-0.55/sbin
mkdir /app/mtr-0.55/sbin
/usr/bin/ginstall -c mtr /app/mtr-0.55/sbin/mtr
chmod u+s /app/mtr-0.55/sbin/mtr
make install-man8
make[3]: Entering directory `/home/jpiszcz/mtr-0.55′
/bin/sh ./mkinstalldirs /app/mtr-0.55/man/man8
mkdir /app/mtr-0.55/man
mkdir /app/mtr-0.55/man/man8
/usr/bin/ginstall -c -m 644 ./mtr.8 /app/mtr-0.55/man/man8/mtr.8
make[3]: Leaving directory `/home/jpiszcz/mtr-0.55′
make[2]: Leaving directory `/home/jpiszcz/mtr-0.55′
make[1]: Leaving directory `/home/jpiszcz/mtr-0.55′
jpiszcz@jpt2:~/mtr-0.55$ relink
6 link(s) installed
jpiszcz@jpt2:~/mtr-0.55$
As you see, mtr 0.55 is now installed.
jpiszcz@jpt2:~/mtr-0.55$ mtr
mtr: Unable to get raw socket. (Executable not suid?)
jpiszcz@jpt2:~/mtr-0.55$ which mtr
/vapp/sbin/mtr
jpiszcz@jpt2:~/mtr-0.55$ readlink `which mtr`
../../app/mtr-0.55/sbin/mtr
jpiszcz@jpt2:~/mtr-0.55$
jpiszcz@jpt2:~/mtr-0.55$ mtr –version
mtr 0.55
jpiszcz@jpt2:~/mtr-0.55$
Now assume you want to upgrade to mtr 0.58 as you may have just seen
a new release announcement on http://freshmeat.net/
There are two ways of upgrading, the right way(1) and the wrong way(2).
The right way:
The right way is to first move the old application out of /app, relink
then continue to configure, make, make install && relink the new
version.
jpiszcz@jpt2:~$ mv /app/mtr-0.55/ ./mtr-0.55-old
jpiszcz@jpt2:~$ relink
6 link(s) removed
jpiszcz@jpt2:~$ cd mtr-0.58 ; conf ; make install ; relinkjpiszcz@jpt2:~$ cd mtr-0.58 ; conf ; make install ; relink
Autoconfigure for /app piszcz v1.0
pkgName: mtr-0.58
newDir: /app/mtr-0.58
./configure –prefix=/app/mtr-0.58
creating cache ./config.cache
checking for a BSD compatible install… /usr/bin/ginstall -c
checking whether build environment is sane… yes
checking whether make sets ${MAKE}… yes
checking for working aclocal… found
checking for working autoconf… found
checking for working automake… found
checking for working autoheader… found
checking for working makeinfo… found
checking for gcc… gcc
checking whether the C compiler (gcc ) works… yes
checking whether the C compiler (gcc ) is a cross-compiler… no
checking whether we are using GNU C… yes
checking whether gcc accepts -g… yes
checking size of unsigned char… 1
checking size of unsigned short… 2
checking size of unsigned int… 4
checking size of unsigned long… 4
checking for tgetent in -ltermcap… yes
checking for initscr… no
checking for initscr in -lncurses… yes
checking for attron… yes
checking how to run the C preprocessor… gcc -E
checking for ncurses.h… yes
checking for ncurses/curses.h… yes
checking for curses.h… yes
checking for cursesX.h… no
checking for sys/types.h… yes
checking for sys/xti.h… no
checking for floor in -lm… yes
checking for gtk-config… /usr/bin/gtk-config
checking for GTK – version >= 1.0.0… yes
checking for socket… yes
checking for gethostbyname… yes
checking for seteuid… yes
checking for res_mkquery… no
checking for res_mkquery in -lbind… no
checking for res_mkquery in -lresolv… yes
checking for herror… yes
checking for strerror… yes
checking for C flags to get more warnings… -Wall
updating cache ./config.cache
creating ./config.status
creating Makefile
creating img/Makefile
creating config.hreal 0m16.497s
user 0m10.340s
sys 0m3.540s
make all-recursive
make[1]: Entering directory `/home/jpiszcz/mtr-0.58′
Making all in img
make[2]: Entering directory `/home/jpiszcz/mtr-0.58/img’
make[2]: Nothing to be done for `all’.
make[2]: Leaving directory `/home/jpiszcz/mtr-0.58/img’
make[2]: Entering directory `/home/jpiszcz/mtr-0.58′
gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -Wall -c mtr.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -Wall -c net.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -Wall -c dns.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -Wall -c raw.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -Wall -c split.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -Wall -c display.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -Wall -c report.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -Wall -c getopt.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -Wall -c getopt1.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -Wall -c select.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -Wall -c gtk.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -Wall -c curses.cgcc -g -O2 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include \
-I/usr/X11R6/include -Wall -o mtr gtk.o curses.o mtr.o net.o dns.o raw.o split.o \
display.o report.o getopt.o getopt1.o select.o -lresolv -lm -lncurses -ltermcap \
-L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXext -lX11 -lm
make[2]: Leaving directory `/home/jpiszcz/mtr-0.58'
make[1]: Leaving directory `/home/jpiszcz/mtr-0.58'real 0m21.299s
user 0m18.870s
sys 0m1.060sif everything looks good: make install
Making install in img
make[1]: Entering directory `/home/jpiszcz/mtr-0.58/img'
make[2]: Entering directory `/home/jpiszcz/mtr-0.58/img'
make[2]: Nothing to be done for `install-exec-am'.
make[2]: Nothing to be done for `install-data-am'.
make[2]: Leaving directory `/home/jpiszcz/mtr-0.58/img'
make[1]: Leaving directory `/home/jpiszcz/mtr-0.58/img'
make[1]: Entering directory `/home/jpiszcz/mtr-0.58'
make[2]: Entering directory `/home/jpiszcz/mtr-0.58'
/bin/sh ./mkinstalldirs /app/mtr-0.58/sbin
mkdir /app/mtr-0.58/sbin
/usr/bin/ginstall -c mtr /app/mtr-0.58/sbin/mtr
chmod u+s /app/mtr-0.58/sbin/mtr
make install-man8
make[3]: Entering directory `/home/jpiszcz/mtr-0.58'
/bin/sh ./mkinstalldirs /app/mtr-0.58/man/man8
mkdir /app/mtr-0.58/man
mkdir /app/mtr-0.58/man/man8
/usr/bin/ginstall -c -m 644 ./mtr.8 /app/mtr-0.58/man/man8/mtr.8
make[3]: Leaving directory `/home/jpiszcz/mtr-0.58'
make[2]: Leaving directory `/home/jpiszcz/mtr-0.58'
make[1]: Leaving directory `/home/jpiszcz/mtr-0.58'
6 link(s) installed
jpiszcz@jpt2:~/mtr-0.58$jpiszcz@jpt2:~/mtr-0.58$ mtr --version
mtr 0.58
jpiszcz@jpt2:~/mtr-0.58$
You have now successfully upgraded mtr from 0.55 to 0.58!
The wrong way:
jpiszcz@jpt2:~$ ls -ld /app/mtr*
drwxr-xr-x 4 jpiszcz users 96 May 27 01:09 /app/mtr-0.55/
jpiszcz@jpt2:~$ cd mtr-0.58
jpiszcz@jpt2:~/mtr-0.58$ make install > /dev/null
mkdir /app/mtr-0.58
mkdir /app/mtr-0.58/sbin
mkdir /app/mtr-0.58/man
mkdir /app/mtr-0.58/man/man8
jpiszcz@jpt2:~/mtr-0.58$ relink
6 link(s) installed
jpiszcz@jpt2:~/mtr-0.58$ ls -ld /app/mtr*
drwxr-xr-x 4 jpiszcz users 96 May 27 01:09 /app/mtr-0.55/
drwxr-xr-x 4 jpiszcz users 96 May 27 01:15 /app/mtr-0.58/
jpiszcz@jpt2:~/mtr-0.58$ mtr --version
mtr 0.55
jpiszcz@jpt2:~/mtr-0.58$ # The first installed version is used first.
jpiszcz@jpt2:~/mtr-0.58$ cd
jpiszcz@jpt2:~$ mv /app/mtr-0.55/ ./mtr-0.55-old
jpiszcz@jpt2:~$ relink
6 link(s) removed
jpiszcz@jpt2:~$ mtr --version
-su: /vapp/sbin/mtr: No such file or directory
jpiszcz@jpt2:~$ # What? This is another known bug.
jpiszcz@jpt2:~$ # relink -i to fix it.
jpiszcz@jpt2:~$ relink -i
APPDIR: /a/app
RELINK>> Delete all files in current directory
RELINK>> DIRECTORY: /a/vappbin doc etc include lib libexec local man sbin share
RELINK>> CTRL-C to abort, 'Y' to continue: Y
Removing all vapp symbolic link files
/a/rdb
rdb.dat rdb.dat.last
Removing rdb filesExecuting relink: [/a/app/relink/bin/relink] 1148 link(s) installed
jpiszcz@jpt2:~$ mtr --version
mtr 0.58
jpiszcz@jpt2:~$
It is now fixed.Caveats of relink
Every program has bugs, here are the known bugs with relink:1] When first installing relink, you must relink -i twice.
2] You cannot install the man program, ie: /app/man-version.
3] If you have two versions of the same program, the program installed first
will be used, however:If you have:
/app/pine-4.59
/app/pine-4.60
And you had installed 4.60 without moving and relinking the old pine first
then you may get this error when trying to run pine:
pine: command not found.This is a bug, to fix this bug: relink -i (re-initialize database).
Conclusion
Despite a few known caveats of relink, I find it to be the most useful package management tool that I have ever used. I have tried other tools in the past such as epkg, but they do not compare to relink. The reason for trying other package management tools is because I wanted a tool that was written in C/C++ because I thought Perl was inferior to C/C++ which turned out to be a very big mistake! I have learned that Perl is just as powerful as C or C++ for the programs people write! I had tried all of the package management tools I could get my hands on that were the most popular at the time. Every time I tried a different package management program, I could never compete with the ease of use and flexibility of relink; there was always some aspect of deb,rpm,tgz that was either tying me down or made things non-portable. In my opinion, relink has outperformed all other package management systems out there; therefore I will continue to use it until I find or write something better.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.
Hmz I thought this would allow me to actually re-link a program so that if a binary package was linked to libsomething-1.1.1.so that I could relink it to libsomething-1.1.2.so. I had to make a symlink for libpng once to make a binary-only package work with my version of libpng. It didn’t pose a problem in this case. Although any real ‘relink’ tool should be able to find out if it’ll work at relinking time.
Anyways, I think ‘relink’ is a very confusing name for a package management tool.
Not another bad comparision between rpm and dpkg!
.deb is comparable to .rpm as it is the actual format of the package and how the database of files, package versions, etc… are saved on your system.
Above .deb or .rpm can sit apt or yum(only for rpm atm) which handles repository installation, and multipackage operations.
So why do people compare dpkg (a frontend to apt on debian) to rpm (a package format)? Its really not that hard to understand!
Here’s three tips regarding lib dependencies…
1) man ldd
2) cat /etc/ld.so.conf
3) man ldconfig
Explanation…
1) You can find out the lib dependencies of ANY program with this command (try ldd /bin/ls).
2) Believe it or not, you can actually add ANY additional lib locations in this file… after which you should run ldconfig.
3) The first three lines of this man page should be more than enough info.
And it really pisses me off for someone to say that these three steps are not “newbie friendly” enough. I mean how hard can this be? Isn’t it roughly the same as how Windows programs scream about missing DLLs?
I really fail to see how installing relink can qualify to be more user-friendly than the steps I’ve mentioned.
I also have found no distribution that does what relink does by installing applications like the following example: /app/program-1.0/{bin,etc,man,lib,sbin}.
There is one, it is called “GoboLinux”:
http://www.gobolinux.org/
Regards,
Offer
I would mention the apps etc directory during upgrade. Some programs update their etc files inline and also removing the old etc dir loses the users configs
Great job!
“So why do people compare dpkg (a frontend to apt on debian) to rpm (a package format)? Its really not that hard to understand!”
Apt is a frontend to dpkg, not the other way around. Check out the package description at http://packages.debian.org/unstable/base/apt and see for yourself.
How is relink different from good ol’ GNU stow? GNU stow have existed literally for ages, and I am happy with it when it comes to installation from source. What advantages does relink offer over stow?
“And it really pisses me off for someone to say that these three steps are not “newbie friendly” enough. I mean how hard can this be? Isn’t it roughly the same as how Windows programs scream about missing DLLs?”
If you feel that going and looking up man pages and then figuring out from that how to resolve dependancies is newbie friendly then it’s obviously been a long time since you were a newbie.
Oh and I’ve not for a long long long time had a DLL dependancy error while installing applications. While building them yes, installing them no, so comparing the regular issue of dependancy problems (affects the user) with DLL Hell (which is pretty much stuck at the developer level) is a bit naughty.
relink is just like the “pkgviews” part of pkgsrc. You have a depot directory, usually /usr/pkg/packages, where software actually gets installed. Then you can manage views, which are really “link farms”.
The default view is of course /usr/pkg, but you can have others, with a different set of packages installed.
Of course, with pkgsrc, you don’t have to make all the downloading and compiling by yourself. You just do “make install”.
I’ve been using Slackware for about a year now, previously I’ve used Red Hat (hate it with a passion), Mandrake (the newbie-friendliest distro I’ve used), Lycoris (tried to hard to be like Windows).
I got my introduction to Linux via Red Hat 5. Dumped it ASAP (mostly due to winmodem issues, not to mention the tediousness of RPMs). Tried Mandrake 8.x (can’t remember the point release), loved it… but I never actually learnt anything about Linux. Soon after, I gave Slackware a try, and I’ve learnt more about Linux during this past year as compared to 5+ years of using RH and Mandrake.
Anyway, what’s wrong with referring to manuals when you have a problem with something? Not just talking about OSs here, but machinery, electrical equipment, and other hardware. The only (quite dumb) excuse that I can think of is that there’s no possibility of people getting injured or dying if they used their OS improperly… hence, most won’t bother.
So if newbies aren’t using it, it does not mean that it’s not user-friendly, please, give manuals a try… Sure, it might not be pretty, but most of the man pages are really straight to the point.
Regarding the DLL hell, sure, nowadays it’s quite rare, unless of course the app you’re trying to install insists on some strange MSVBVM30.DLL (I made this up purely for example, it most likely doesn’t even exist) that was popular aeons ago. However, there’s a new flavour of it right now… .NET Framework files (how big is this beast now, 10MBs?). And IIRC, whenever a new version of this runtime comes out, we do have to reinstall the WHOLE framework right, not just the particular updated part that we actually need.
I might be totally wrong though, please point out my mistakes if any… I’m really here to learn, and I’m more than willing to receive positive criticism.
You have the Linux 2.4.26 kernel source. Fact: You want to install the newest 2.4.xx kernel. Problem: You have GCC-3.4.0 installed. Solution: Install gcc-3.3.3 and use gcc-config to switch between the two at will.
Gentoo already automates installs of different versions of sofware like different major versions of kernels, gcc, java environments, kde, gnome. For better relink PR, use better examples; problems only relink solves but no other package management tool.
Man, this is old news.
I’ve created a very similar tool over 6 years ago (called ‘engage’), entirely written as a shell script (using find and sed). My later implentations inspired by the ‘en(able)’ scripts from Hubert Feyrer (of NetBSD fame), although before that I used a totally different design and implementation.
We both had a similar idea (independendly), so this concept of ‘relink’ is definitely not really a great unique invention, it is just something that you will come up yourself eventually. I’m sure others have created a app like ‘relink’ aswell, long time ago.
Back in the those days I even based my whole DIY-linux system on this principle (I still have it on installed on my old P133). When I was working at Sun Microsystems, I was approached whether they could use it, so I released it under GPL. (I actually don’t know whether they really used it internally, since this was just before I left Sun).
To be honest, I haven’t use it for ages. Mainly because I swiched to Debian long time ago, and there was no real need for me to use it anymore.
I definitely vote for this way of organizing packages (all the way down to glibc). Can we have it in a major distribution please?
epkg does the trick for me (on an LFS system).
I use a Perl script called Graft (search Freshmeat) that does a similar job. This kind of software install scheme is outlined in a Sun paper called “The Art of Automounting” by Martien F. van Steenbergen and covered by Limoncelli & Hogan in Practice of System and Network Administration. It’s definitely the way to go if you want to compile from source and still keep package files together. It also gives you a rollback path to previous versions.
While I do kinda see how this is unique, multiple versions of packages live in Gentoo quite nicely…and the gcc-config program can handle multiple versions of gcc, if I’m not mistaken. The “USE” variable in gentoo lets you control features with relative ease, especially with handy ncurse-based frontends like ufed to make things more clear to the more casual user. Gentoo even handles a system with 2.4 and 2.6 kernels installed!
So how *exactly* is this dissimilar to Gentoo, with the exception of the path name changes…? I don’t want a rant, just an answer.
“So why do people compare dpkg (a frontend to apt on debian) to rpm (a package format)? Its really not that hard to understand!”
So what exactly is the binary used to install/upgrade/etc the .rpm’s called? I always thought that it was rpm, but I am clearly mistaken.
About .NET versioning:
1. .NET supports side-by-side installation which means you can have any number of .NET runtimes installed and there’s a future-compatible infrastructure to tell your application which runtime it should use.
2. .NET versioning model assumes (quite correctly) that applications work best when they run with the same libraries they were compiled with. If you test your application and you know it works with other runtime you can allow it by providing assembly redirection rules. Without your explicit permission it won’t run (core assemblies are the exception, because .NET provides transparent redirection for them)
3. .NET supports loading assemblies side-by-side which means you can have two versions of a single component loaded into one process.
4. There’ve been two versions of .NET released so far. I don’t see how this can be a DLL-hell.
Phew! I’ll keep my slackware box on a checkinstall diet I think!
Sorry, I made a typo. I havn’t used debian in a while and I confused the tasksel package (or whatever it is called that provides easy access to apt, and dpkg comparable to the rpm layer. But dpkg does not do auto-dependency resolving just like rpm! dpkg and rpm are mostly the same. The reason debian dosn’t have dependency issues is because of apt, which exsits for rpm too, in addition to yum.
So my original post (IP: —.sothfd01.mi.comcast.net) is correct, I just confused one of the names. Sorry, I havn’t used debian in a long while.
synaptic == synaptic (apt-get only)
aptitude == …
apt-get == yum,apt-get
dpk == rpm
I’m not implying that requirements of the .NET Framework is just like DLL hell. The only similarity (that I can think of as an end user) is that the framework is required by apps that use it, of course.
However, the similarities with some core Linux libs, is that the size of each release is MASSIVE. That is what I meant by its “flavour”. Let’s say we’re trying to run a simple 100k text editor, we’re gonna need 10s of MBs worth of libs.
However, thanks for the explanation of the co-existing versions of the framework playing nice with each other. At least I learnt something new today
“The reason debian dosn’t have dependency issues is because of apt, which exsits for rpm too, in addition to yum.”
It’s not as simple as that. Note for instance that rpm still has no support for “enhances”, “suggests” or “recommends” relationships between packages, regardless of what frontend you’re using.
i dont realy see the point of those 3 fields unless you have a popup or similar while installing saying “hey, this package recommends that you install those packages, suggests these and it just wnats you to know that it enhances that pacakge over there”. as long as i tells you want packages it needs to have preinstalled for its content to work then it telling me all i need (except maybe a url or similar pointing me to where i can find them if they are not present)…
what is realy needed is for integration with kde/gnome so that you can “run” on a package file from there, have it passed to the pacakge manger for parseing and dependency resolving and if failure give the user a hint about go search say rpmfind or similar for the missing packages (or maybe this can be done by the manager. or the package can provide a default download site for its dependencys). this way the packages becoems as user friendly as the installer files in windows in my view.
Today I had a situation on Redhat Advance Server 3.
it comes with glibc 3.2. I need to run glibc 2.9, taking the rpms from AS 2 force me to do rpm -ivh –force -nodeps.
is relink the answer to this? is it ldconfig?
i dont realy see the point of those 3 fields unless you have a popup or similar while installing saying “hey, this package recommends that you install those packages, suggests these and it just wnats you to know that it enhances that pacakge over there”. as long as i tells you want packages it needs to have preinstalled for its content to work then it telling me all i need (except maybe a url or similar pointing me to where i can find them if they are not present)…
Actually, apt does tell you those things when you are installing. It has been quite useful to me. When installing (oh, let’s say) “emacs” it might tell you that “emacs-dev,” “emacs-doc” or “emacs-elisp” is suggested. Emacs will still work without the suggested packages, so they aren’t required. But it is nice to have the documentation or the development libraries sometimes. The “suggests” field tells me that there are other parts of the package that are not required, and gives me the names so I can install them if I wish.
-Signals
While I admire your efforts at solving a problem that affected you, you may have benefitted from some more in depth research first. There are a number of packages that do the same or very similar things. In my research I encountered the following (roughly oldest package first)
depot
stow
graft (disclaimer, I am the author of graft)
encap
stowES
opt_depot
relink
None of these did what I wanted so I wrote graft (which predates relink by about 4 years so that’s why I didn’t consider relink when writing graft). From your usage examples I think graft still does a better job because it manages the package removal without really removing the package, only the symlinks.
For more details on my own research and graft, see
http://www.gormand.com.au/peters/tools/graft/graft.html
I might say this would be a good package tool for LFS. And I can see a lot of room for improvements in order to make it ideal for LFS.
The concept is so simple, each app has its own install location, make a link somewhere so that other apps that use it can find them. By putting a central install location, accounting of apps is simple as doing an ls. Removing is also simple as deleting the directory. By using hard links, deleting the files will also delete the link. To make back-up, just copy the whole directory. To restore, copy back the directory and re-create the links.
That’s it, this would be a good concept for LFS.
Regards.