Showing posts with label rpm. Show all posts
Showing posts with label rpm. Show all posts

Tuesday, May 17, 2011

Developing packages with RPM

Reference: Max RPM book, Edward C. Bailey

Building a package is similar to compiling code—there are inputs, an engine, and outputs.
Inputs
1) Sources - It should be a tar file. RPM can handle other archive formats, but a bit more up-front effort is required.
2) Patches - RPM gives you the ability to automatically apply patches.
3) Spec File - It contains information required by RPM to build the package, as well as instructions telling RPM how to build it. It also dictates exactly what files are a part of the package, and where they should be installed. There are eight sections in spec file
  3.1 - The Preamble  - It contains information that will be displayed when users request information about the package. This would include a description of the package’s function, the version number of the software, and so on.
  3.2 - The Prep Section - necessary preparations are made prior to the actual building of the software. The contents of this section are an ordinary shell script. However, RPM does provide two macros. One macro can unpack a compressed tar file and cd into the source directory. The other macro easily applies patches to the unpacked sources.
  3.3 - The Build Section - The build section consists of a shell script. It is used to perform whatever commands are required to compile the sources. This section could consist of a single make command, or be more complex if the build process requires it.
  3.4 - The Install Section - It also consists of a shell script. It is used to perform the commands required to install the software. This section might only consist of a make install command. Otherwise, the usual assortment of cp, mv, or install commands to get the job done.
  3.5 - Install and Uninstall Scripts - It consists of scripts that will be run, on the user’s system, when the package is actually installed or removed.
  3.6 - The Verify Script - It is executed when RPM verifies the package’s proper installation. While RPM does most of the work verifying packages, this script can be used to verify aspects of the package that are beyond RPM’s capabilities.
  3.7 - The Clean Section - contains a script that can clean things up after the build. This script is rarely used, since RPM normally does a good job of clean-up in most build environments.
  3.8 - The File List - The last section consists of a list of files that will comprise the package. Additionally,
a number of macros can be used to control file attributes when installed, as well as to denote which files are documentation, and which contain configuration information. The file list is very important — if it is missing, no package will be built.

Engine: RPM
It performs a number of steps during the build process:
  *) Executes the commands and macros in the prep section of the spec file.
  *) Checks the contents of the file list.
  *) Executes the commands and macros in the build section of the spec file.
  *) Executes the commands and macros in the install section of the spec file. Any macros in the file list are executed at this time, too.
  *) Creates the binary package file.
  *) Creates the source package file.
     Outputs
     The end product of this entire process is a source package file and a binary package file.
      1) Source package: It is a specially formatted archive that contains the following files - the original compressed tar file(s), spec file, patches. It is a great way to archive all the information needed to rebuild a particular version of the package.
      2) Binary RPM: It contains the files that comprise the application, along with any additional information needed to install and erase it.

    Building packages
    Step 1: Creating the Build Directory Structure
      Default directory layout consists of a single top-level directory (/usr/src/redhat) with five subdirectories.
      /usr/src/redhat/
            SOURCES  -  Contains the original sources, patches, and icon files.
            SPECS - Contains the spec files used to control the build process.
            BUILD - The directory in which the sources are unpacked, and the software is built.
            RPMS - Contains the binary package files created by the build process.
            SRPMS - Contains the source package files created by the build process.

    Tuesday, December 16, 2008

    RPM usage

    Let me show you how to create a simple RPM package.

    Let me brief about few important rpm options.

    INSTALL OPTIONS
    1) How to install a rpm package?
    rpm -ivh epm-3.5.1-1.i386.rpm

    -i : Insists RPM to install
    -v : verbose
    -h : print # as install progess

    2) How to get more verbose information?
    rpm -i
    vv epm-3.5.1-1.i386.rpm

    3) --test: Perform installation test only
    rpm -i --test epm-3.5.1-1.i386.rpm
    rpm doesn't install the package, instead performs all the checks that RPM does during an install. RPM will return a non-zero status if the --test option detects problems…

    4) --replacepkgs: Install the Package Even If Already Installed
    rpm -ivh --replacepkgs epm-3.5.1-1.i386.rpm
    This option is used to force RPM to install a package that it believes to be installed already.

    5) Force full installation with "--force" option
    rpm -ivh
    --force epm-3.5.1-1.i386.rpm
    Here is one situation where you end up using --force option. Assume a previously installed package is deleted manually by a mischievous person. When you try to install it again by just calling "rpm -i *.rpm". It will end up with the message "package epm-3.5.1-1 is already installed". In this situation you can use either --force option or --replacepkgs option.

    6) Installing from URL's
    rpm -i ftp://ftp.gnomovision.com/pub/rpms/foobar-1.0-1.i386.rpm
    Specifying username for FTP site

    rpm -i ftp://smith@ftp.gnomovision.com/pub/rpms/apmd-2.4-1.i386.rpm
      Password for smith@ftp.gnomovision.com: ??

    7) Installing package even if dependent packages are not available on system
     rpm -i --nodeps blather-7.9-1.i386.rpm
    The --nodeps options to an install command directs RPM to ignore any
    dependency-related problems and to complete the package installation.


    8) Avoiding docs getting installed
    rpm -iv --excludedocs cdp-0.33-3.i386.rpm
    Also there is an option --includedocs which directs RPM to install any files marked as
    being documentation.

    9) Installing package on path of our choice
    rpm -i --prefix /tmp/test cdplayer-1.0-1.i386.rpm
    --prefix gives the person installing the package flexibility in determining where on
    their system they should be installed.

    10) --noscripts: Do Not Execute Pre- and Post-install
    Scripts

    11) --percent
    RPM displays a series of numbers. Each number is a percentage that indicates how far along the
    install is. When the number reaches 100%, the installation is complete.
    rpm -i --percent iBCS-1.2-3.i386.rpm

    12) --rcfile : Use As An Alternate rpmrc File
    The --rcfile option is used to specify a file containing default settings for RPM. By default, RPM uses /etc/rpmrc and a file named .rpmrc located in your login directory.

    13) --root : Use As An Alternate Root
    Adding --root to an install command forces RPM to assume that the directory specified by is actually the "root" directory. The --root option affects every aspect of the install process, so pre- and post-install scripts are run with as their root directory.

    14) --dbpath : Use To Find RPM Database
    Normally, RPM database exists in the directory specified by the rpmrc file entry, dbpath. By default, dbpath is set to /var/lib/rpm.

    15) --ftpport : Use In FTP-based Installs

    16) --ftpproxy : Use As Proxy In FTP-based Installs

    17) --ignorearch: Do Not Verify Package Architecture
    When a package file is created, RPM specifies the architecture, or type of computer hardware, for which the package was created. This is a good thing, as the architecture is one of the main factors in determining whether a package written for one computer is going to be compatible with another computer.

    The --ignorearch option will not perform any architecture-related checking.

    18) --ignoreos: Do Not Verify Package Operating System
    When a package file is created, RPM specifies the operating system for which the package was created. This is a good thing as the operating system is one of the main factors in determining whether a package written for one computer is going to be compatible with another computer.

    The --ignoreos option will not perform any operating system-related checking.

    19) --replacefiles: Install the Package Even If It Replaces Another Package’s Files
    rpm -iv --replacefiles cdp-0.33-3.i386.rpm

    ERASE OPTIONS
    1) How to un-install a package?
    rpm -ev eject 
     -e: erase
    -v: verbose

    To get even more verbose information
    rpm -evv eject

    By adding -vv to the command line, we can often get a better feel for what’s going on inside RPM.

    By default RPM wouldn’t erase the package if there are dependencies for this package.


    2) --test: Go through the process of erasing the package, but do not erase it
    rpm -e --test bother
    It will show if any files needed by other packages getting deleted if we erase this package.

    3) --nodeps: do not check dependencies before erasing package
    rpm -e --nodeps bother
    Adding the --nodeps options to an erase command directs RPM to ignore any dependency-related problems, and to erase the package.

    4) --noscripts: do not execute Pre- and Post-uninstall scripts 

    5) --rcfile : Read for RPM Defaults
    The --rcfile option is used to specify a file containing default settings for RPM. By default, RPM uses /etc/rpmrc and a file named .rpmrc located in your login directory.

    6) --root : Use as the root
    Adding --root to an un-install command forces RPM to assume that the directory specified by is actually the "root" directory. The --root option affects every aspect of the install process, so pre- and post-install scripts are run with as their root directory

    7) --dbpath : Use to find RPM Database
    Normally, database exists in the directory specified by the rpmrc file entry, dbpath. By default, dbpath is set to /var/lib/rpm.

    8) rpm -e and Config files
    If you’ve made changes to a configuration file that was originally installed by RPM, your changes won’t be lost if you erase the package. Say, for example, that we’ve made changes to /etc/skel/.bashrc (a config file), which was installed as part of the etcskel package. Later, we remove etcskel, .bashrc.rpmsave a copy of your modified .bashrc file will be created during un-install.

    UPGRADE OPTIONS
    1) How to upgrade a already installed package?
    rpm -U eject-1.2-2.i386.rpm
    If a package not installed at all early, then -U option works similar to -i (install) option.

    Given the fact that rpm -U can be used as a replacement to rpm -i, it follows that
    most of the options available for rpm -U are identical to those used with rpm -i.

    URLs can also be used to specify the package file.

    2)  --oldpackage: Upgrade to an older version
    rpm -Uv --oldpackage cdp-0.33-2.i386.rpm

    3) --force: Forceful up-gradation
    It adds --replacepkgs, --replacefiles, and --oldpackage to the command. The only thing that will prevent a --force’ed upgrade from proceeding is a dependency conflict.

    4) --noscripts: Do not execute Install and Uninstall Scripts

    QUERY OPTIONS
    Format: rpm -q   <information-selection>
    Where Package name can be
      -
    7) How to view content of RPM package using RPM command?
    rpm -q -filesbypkg -p filename.rpm (or similar)
    where --filesbypkg means "List all the files in each selected package."