A package processed by sourceinstall can exist in three forms:
For example, if you are short on space, and you are installing a conforming package (so you get a list of installed files in the package details), you can decide to remove the archived source (losing all the advantages though) to free up some space. Alternatively, you can avoid to store it in the first place when you perform the Add action.
On the countrary, you might think that you do not require a certain installed
program right now, so you select the Remove action for that package, but
remove only the installation and not the source, so you can quickly reinstall should you require the software again in the future. Your configuration will
be preserved, you will not need to pass through the configuration window anymore if you were fine with the last installation.
Another service that sourceinstall offers is a simple set of consistency checks for existing installations.
In the Tk interface, selecting a package from the list at any time will show all available information about the installed package, and a check will be performed to see if the install looks ok. If some of the files required by the program are missing, you will find a notice and all the missing files will be highlighted and marked with asterisks (*).
The same thing can be obtained from the command line interface using the --check action.
At this point you can correct the problem by restoring the missing files yourself (for example, you might have accidentally moved them for arcane reasons), or
just reinstall the package, using the Reinstall button of the Tk interface, or the --install action of the command line one.
Additionally, during the uninstallation cross-checks will be performed between make uninstall results and internal package information; only independent files (that is, files that are not being claimed by other packages) are proposed for removal (Tk interface), or directly removed (command line interface).
This works better if you avoid installing non-conforming packages, because Source Installer will not be able to know which files a non-conforming package claims.
It is recommended to install only conforming packages using Source Installer. Conforming packages offer a configure script that generates a Makefile, and the Makefile honors the common install targets and environment variables. Generally, packages built (correctly) with the GNU autotools result as conforming packages, and the autotools are also expecially supported: only configure scripts generated with autoconf get the nice configuration window in the Tk interface. However, there are also other tools that developers can use which are capable of producing a configure script and a Makefile. Even hand-written configure scripts and Makefiles are ok, as long as they honor the install targets and the environment variables.
Conforming packages get better uninstallation, better checks, more information in the Package information window. A single non-conforming package can make uninstallation checks degrade. This is because the program can not detect which files a non-conforming package claims.
For these reasons, you will be warned when installing a non-conforming package.
It is highy probable that you will have many different tools that provide package management. For example, if you are running a GNU/Linux distribution, you probably have your distribution-specific way to handle binary (or even source) packages. What I suggest here is to make a clean separation between your distribution-provided packages (along with any additional packages installed using your distribution-specific tools), and the source packages installed using the distribution-independent GNU Source Installer. One good way to obtain this, is to use different prefixes for each package management system you use. Suppose your distribution-handled packages are in /usr, then your source packages managed by GNU Source Installer can be prefixed using /usr/local (this is the initial value). This way you ensure that file dependency checks are not tainted by other packages managed by other tools.
GNU Source Installer configuration and packages always refer to the particular user that runs it. What follows is a list of possible setups.
As the first example, suppose user Pip wants to install his private packages. He chooses to install in /home/pip/usr, at the same time allowing user Merlin to install his own packages in /home/merlin/usr. Of course, in this case no one steps on anybody's toes and everything runs smooth.
As the second example, user Merlin is the system administrator, and personally deals with all system-wide package installations. Thus, he logs in using his merlin account, then runs sourceinstall and uses the default prefix value, which is /usr/local to install new programs. When requested by the system, he is asked for the root password. This is ideal for one-user systems.
As a third example, suppose both Pip and Merlin deal with system administration. They get along well, and both deal with system-wide package installations. Thus, they decide to both install packages logging in using the privileged root account, and then install using sourceinstall. They will both see the same packages, because they are logging in as the same user (root). However, only one of the two admins will be able to install software at the exact same time, because to prevent corruption of package data each user is entitled to a single running instance of GNU Source Installer. When the program is already in use, sourceinstall refuses to start and explains the error.
As a last example, here's what not to do. Imagine both Pip and Merlin deal with system administration, like before, but since they don't read the docs, they login using their regular accounts, and perform installs using the default system-wide prefix, /usr/local, providing the root password when needed. Even if they install at different times this is a bad thing to do: they will not be aware of each other's moves, file dependency tracking will be far less precise, and uninstallation crosschecks will degrade.
If you want to dwell on the internals of sourceinstall, this is an interesting chapter. We will look at all files and directories that together make sourceinstall work.
The sourceinstall executable is in fact a symbolic link to the implementation in use. For example:
$ ls -l /usr/bin/sourceinstall*
lrwxrwxrwx 1 root root 11 Jun 3 03:15 sourceinstall -> sourceinstall.tcl
-rwxr-xr-x 1 root root 87019 Jun 3 03:15 sourceinstall.tcl
Currently there is only a tcl implementation, but in the future this system will be used to make different implementations of sourceinstall coesist.
The per user configuration directory is another story:
each user that runs sourceinstall gets a .sourceinstall directory created in his HOME. This is for example a directory tree:
$ tree ~/.sourceinstall /home/claudio/.sourceinstall |-- build |-- install-destdir |-- packages | |-- a-renet-1.1.0rc5 | |-- cmdftp-0.9.2 | `-- libmikmod-3.2.0-beta2 |-- src | |-- a-renet-1.1.0rc5.tar.bz2 | |-- cmdftp-0.9.2.tar.bz2 | `-- libmikmod-3.2.0-beta2.tar.bz2 `-- sourceinstallrc
If sourceinstall were running, you would see another file, ~/.sourceinstall/.sourceinstall_lock, containing the process id of the running sourceinstall process.
In this case there are only three packages installed. Each package has a file name entry with the same name in the packages directory. That file contains all information on that package.
The source for all three packaged has been archived in the src directory.
The install-destdir directory is used during the test installation, and then it is cleared.
The build directory is used only while building packages, and then it is cleared.
Do not store anything in these directories yourself, because they will be regularily emptied.
The sourceinstallrc file contains the current user preferences. These are the same options that can be tweaked from the Preferences in the Edit Menu using the Tk interface.
sourceinstall contains now some experimental export functions, to offer more interface to other programs (and some user functionalities as well).
Information about a single package (or about all the packages) can be exported through the Export package information to XML and Export package information to plaintext features. The XML involved is a simple XML 1.0 format (look at the XML output for the external public DTD address) and is more machine-oriented, while the plaintext is more user-oriented.
It is also possible to extract just the list of the files claimed by the installed package, in a plaintext, newline-separated list using the Export installed files list action.
A whole different story is the Export as binary package functionality. Information that follows is very unstable and should not be relied upon for the long term. This is a simple function that builds a .tar.gz archive out of the files, directories and links claimed by an installed package. Original file permissions and ownership will be preserved. It should be easy to build OS-specific binary packages out of these simple binary tarballs. However, also consider using the export installed files list functionality instead. If you expected more binary package building functionalities, please remember that this program is source-centered and OS-neutral.