Sooner or later poor WinXXX users learn that “exe” files are executables. Why “poor users”? Mainly because they get only the executables.
A GNU/Linux system is built out of sources. In a pure GNU system one can see all the sources. Of course, the computer can run only the executables. Thus one has to build executables under GNU/Linux (see an example in the corresponding image).
Let's say that you have mastered the usual
./configure
make
make install
incantation.
Even if it is possible to
make uninstall
it is difficult to manage the maze of installed executables.
The solution? A package manager. I will use here the example which is familiar to me, the RPM package manager.
First one should browse the RPM documentation.
Mike A. Harris has a note on how one can build RPMs as a non-root user.
After looking at these documents one might ask herself/himself a series of questions.
Why build yourself (some) of the RPMs? Aren't repositories of RPMs available? Yes, there are repositories, but I like sometimes to adapt the RPMs or even to manage the executables in a different way (as in the case of LATEX , for example).
Anyway, building at least some of the RPMs gives you a better understanding of the maze of files in a GNU/Linux system.
Why would one build as non-root? First, the mistakes one makes as root might ruin the system. Second, at the office one might have no access to root rights. Thus one has to build in her or his own home.
First you have to create a dot file in your home. The rpmbuild command needs this file.
The name of the file is
.rpmmacros
It has to contain at least a line like this
%_topdir /home/snoopy/rpm
Of course, snoopy is the name of the user. I use rpm as the name of the folder where I build the RPMs.
Some people like to change the folder structure of the “building site”. I have kept the standard structure (see the image).
The folders in the first row (those with names in uppercase) are the standard folders. Inside RPMS you also need the folders i386, noarch and so on, according to what you build.
The second row in the image contains folders added by me. Their names are not standard.
[Note on 2008-12-21: for further examples look at the note on pdf2djvu RPM building.]
Frank Richter has an excellent GUI for looking-up in dictionaries. It comes with a German-English dictionary. There is also available for download a src RPM.
Let's say that we do not have root access, but we need the german dictionary. We will put it in our home. We could do this in “brute force” fashion, but we will use the RPM building process.
First look at the src RPM. Under Fedora GNU/Linux, you can open it clicking on the right button of the mouse and then on “Open with the Archive Manager”. In the GUI interface of the archiver we will see a spec file and a tar.gz file.
Let us open the tar.gz file. This is an archive of the source files. For short, this is the source!
We open the source with the archiver. The key file is ding. It is a Tcl/Tk script. Thus it is not going to be compiled. The main program, in this case, is interpreted as we run it.
By default, ding looks for dictionaries in a folder which is under root control. The source is under GPL, we can adapt it. On line 88 we put something like
/home/snoopy/share/dict/de-en.txt
replacing the default path. The same change is operated on line 885. This is obviously not a big change, but it would be impossible (for technical or legal reasons) in a closed source program, even if we have only the intention to adapt the program for use just on a single, private computer.
We also have to adapt the ding.desktop file. The user “snoopy” has put her/his own path to the executable ding file (see the image).
Then we have to archive back the tar.gz file. We place it in the SOURCES folder of the RPM “building site”.
Now, we have to turn our attention towards the spec file. There it is written the “scenario” for the building of the package. The spec is going to be adapted for an installation in the home directory.
Do not confound the building of the RPM in the home directory with the installation of the files in the home directory! You may put the files in other places too. I just made the minimal assumption that you do not have root access.
In the spec file, the RPM_BUILD_ROOT paths are modified for the home directory.
%attr(
%defattr(-,snoopy,users)
means that snoopy is the user and users is the group.
Pay attention to the location of ding.desktop and ding.png
In %changelog put a note about the changes, otherwise you might think it is the original spec file or, worse, confuse other people.
The main changes are shown in the corresponding image. In the spec file the location of the files is in snoopy's home. Indeed, the advantage of the home installation is that it is now extremely easy to change a dictionary. You do not have to be root to do the changes.
This is a very simple example as it does really involve only the packaging of the files.
The RPM build command, in our example, is:
rpmbuild -bb ding-1.5.spec
To be non-root to the end you need a data-base for RPMs in your home folder.
Initialize the data-base with a command like
rpm --initdb --dbpath /home/snoopy/rpm/z-db
Install the package:
rpm -Uvh --dbpath ~/rpm/z-db ding-1.5-1.fc7.noarch.rpm --nodeps
You need --nodeps because, for example,
rpm -q tcl
tcl-8.4.13-16.fc7
but this is an information you get from the central /var/lib/rpm database.
You know what packages you have installed locally with a command like
rpm -q --dbpath ~/rpm/z-db ding
The answer could be, according to what is installed, like this
ding-1.5-1.fc7
If you ask yourself what package has put ding in your bin folder, the RPM data-base has the answer. Query it in this way:
rpm -qf --dbpath ~/rpm/z-db ~/bin/ding
The uninstall command is:
rpm -e --dbpath ~/rpm/z-db ding-1.5-1.fc7
As a bibliographical source I have consulted