9. do /usr/bin/install -c -d /usr/local/share/xmorph/example/$i ;\
10. for j in $i/* ;\
11. do /usr/bin/install -c -m 644 $j \
12. /usr/local/share/xmorph/example/$i; done;\
13. done
14. make[2]: Leaving directory \Q/tmp/xmorph-current'
15. make[1]: Leaving directory \Q/tmp/xmorph-current'
At this point, the software should be ready to use.
5.6.2. How Does It Work?
A tarball is an archive of files created by tar (the tape archiving program) and usually compressed using gzip . By convention, source code tarballs are named <package-version> .tgz and all of the files extract into a directory named <package-version> ; for example, fen-10.4.tgz would extract into the directory ./fen-10.4/ .
Since the 1980s, source packages have often contained a script named configure ; most recent open source projects use versions of this script generated by a tool called GNU autoconf . The configure script adapts the compilation process for various systems; for example, some Unix systems have multiple C compilers installed, or different versions of libraries such as malloc , so configure determines what is available and the compiler options that will be needed to compile the software on the current system.
The output of configure usually includes one or more Makefile s and sometimes a C header file. The Makefile s contain the commands necessary to build the software, as well as dependency information; make uses this file to perform the least amount of work necessary to build the required output files. Another section of the Makefile contains the commands necessary to install the softwareperforming operations such as copying files and creating directoriesand this section is used when the make install command is executed.
The disadvantage of installing software from source is that you lose the benefits of the RPM database. It can be hard to uninstall the software, and you have no record of which version was installed, when it was installed, what dependencies it requires or satisfies, and which files are associated with it. Any updates must be performed manually, and any conflicts that other updates may cause will not be known in advance.
5.6.3. What About...
5.6.3.1. ...packages that are not written in a compiled language?
These packages may still need processing. For example, the manpages may be in a raw format that needs preprocessing, and scripts may need to be adjusted according to where the language interpreter is installed. In most cases, these packages will have a Makefile , just like a compiled package.
5.6.3.2. ...packages that don't have a configure script?
The Makefile may be sufficiently simple or generic that it will work on a wide range of systems, or you may need to adjust it manually. Look for a file named INSTALL or README for information on the steps you need to perform to compile and install the software.
5.6.4. Where Can I Learn More?
The manpages and info pages for autoconf and make
5.7. Making Your Own RPM Packages
While it's fairly easy to install software from source, it's not much more work to build an RPM package, especially if the original source code is well-written and in a traditional tarball. The extra work will make it much easier to track, update, and remove the software installed on your system.
5.7.1. How Do I Do That?
In order to build an RPM, you need to have the original source tarball plus a spec file , which provides most of the metadata for the RPM package and controls how the RPM is builtbut before you build any packages, you should customize your RPM environment.
5.7.1.1. Preparing to build RPMs
RPMs are digitally signed by the packager. Although this is an optional step, it indicates that the package is from a trusted source and provides a way of verifying that no one has tampered with it.
RPM signatures are generated using GNU Privacy Guard ( gpg or gnupg ), which can also be used to sign or encrypt email messages. If you have not created a gpg key, this is a great time to do so:
$ gpg --gen-key
gpg (GnuPG) 1.4.1; Copyright (C) 2005 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
gpg: directory \Q/home/chris/.gnupg' created
gpg: new configuration file \Q/home/chris/.gnupg/gpg.conf' created
gpg: WARNING: options in \Q/home/chris/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring \Q/home/chris/.gnupg/secring.gpg' created
gpg: keyring \Q/home/chris/.gnupg/pubring.gpg' created
Please select what kind of key you want:
(1) DSA and Elgamal (default)
(2) DSA (sign only)
(5) RSA (sign only)
Your selection? 1
DSA keypair will have 1024 bits.
ELG-E keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
Requested keysize is 2048 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 0
Key does not expire at all
Is this correct? (y/N) y
You need a user ID to identify your key; the software constructs the user ID from the Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"
Real name:
Chris Tyler
Email address:
<chris@fedorabook.com>
Comment:
ENTER
You selected this USER-ID: