home *** CD-ROM | disk | FTP | other *** search
/ Caldera Network Desktop 1.0 / caldera-network-desktop-1.0.bin / rpm / RPM-HOWTO.txt < prev    next >
Text File  |  1995-12-18  |  43KB  |  1,453 lines
  1.   RPM HOWTO
  2.   Donnie Barnes, djb@redhat.com
  3.   V1.4, December 5, 1995
  4.  
  5.   1.  Introduction
  6.  
  7.   RPM is the Red Hat Package Manager.  While it does contain Red Hat in
  8.   the name, it is completely intended to be an open packaging system
  9.   available for anyone to use.  It allows users to take source code for
  10.   new software and package it into source and binary form such that
  11.   binaries can be easily installed and tracked and source can be rebuilt
  12.   easily.  It also maintains a database of all packages and their files
  13.   that can be used for verifying packages and querying for information
  14.   about files and/or packages.
  15.  
  16.   Red Hat Software encourages other distribution vendors to take the
  17.   time to look at RPM and use it for their own distributions.  RPM is
  18.   quite flexible and easy to use, though it provides the base for a very
  19.   extensive system.  It is also completely open and available, though we
  20.   would appreciate bug reports and fixes.   Permission is granted to use
  21.   and distribute RPM royalty free under the GPL.
  22.  
  23.   RPM can even provide an excellent method to upgrade an existing
  24.   system.  The database won't be as up to date as a machine that was
  25.   completely installed with RPM, but it will still contain anything
  26.   installed with RPM.  It can also be used to package commercial
  27.   software.
  28.  
  29.  
  30.   2.  Overview
  31.  
  32.   First, let me state some of the philosophy behind RPM.  One design
  33.   goal was to allow the use of ``pristine'' sources.  With RPP (our
  34.   former packaging system of which none of RPM is derived), our source
  35.   packages were the ``hacked'' sources that we built from.
  36.   Theoretically, one could install a source RPP and then make it with no
  37.   problems.  But the sources were not the original ones, and there was
  38.   no reference as to what changes we had to make to get it to build.
  39.   One had to download the pristine sources separately.  With RPM, you
  40.   have the pristine sources along with a patch that we used to compile
  41.   from.  We see this as a big advantage.  Why?  Several reasons.  For
  42.   one, if a new version of a program comes out, you don't necessarily
  43.   have to start from scratch to get it to compile under RHCL.  You can
  44.   look at the patch to see what you might need to do.  All the compile-
  45.   in defaults are easily visible this way.
  46.  
  47.   RPM is also designed to have powerful querying options.  You can do
  48.   searches through your entire database for packages or just certain
  49.   files.  You can also easily find out what package a file belongs to
  50.   and where it came from.  The RPM files themselves are compressed
  51.   archives, but you can query individual packages easily and quickly
  52.   because of a custom binary header added to the package with everything
  53.   you could possibly need to know contained in uncompressed form.  This
  54.   allows for fast querying.
  55.  
  56.   Another powerful feature is the ability to verify packages.  If you
  57.   are worried that you deleted an important file for some package, just
  58.   verify it.  You will be notified of any anomalies.  At that point, you
  59.   can reinstall the package if necessary.  Any config files that you had
  60.   are preserved as well.
  61.  
  62.   We would like to thank the folks from the BOGUS distribution for many
  63.   of their ideas and concepts that are included in RPM.  While RPM was
  64.   completely written by Red Hat Software, its operation is based on code
  65.   written by BOGUS (PM and PMS).
  66.  
  67.   3.  General Information
  68.  
  69.  
  70.   3.1.  Acquiring RPM
  71.  
  72.   The best way to get RPM is to install Red Hat Commercial Linux.  If
  73.   you don't want to do that, you can still get and use RPM.  It can be
  74.   acquired from any Official Red Hat Mirror.  Some of those are:
  75.  
  76.  
  77.        FTP Site                Directory
  78.        ========                =========
  79.        ftp.pht.com             /pub/linux/redhat
  80.        sunsite.unc.edu         /pub/Linux/distributions/redhat
  81.        sunsite.doc.ic.ac.uk    /packages/linux/sunsite.unc-mirror/
  82.                                        distributions/redhat/redhat-2.0
  83.        ftp.cms.uncwil.edu      /linux/redhat
  84.        ftp.wilmington.net      /linux/redhat
  85.        ftp.caldera.com         /pub/mirrors/redhat
  86.        ftp.lasermoon.co.uk     /pub/distributions/RedHat
  87.        ftp.cc.gatech.edu       /pub/linux/distributions/redhat
  88.        uiarchive.cso.uiuc.edu  /pub/systems/linux/distributions/redhat
  89.        ftp.ibp.fr              /pub/linux/distributions/redhat
  90.        ftp.gwdg.de             /pub/linux/install/redhat
  91.        ftp.uoknor.edu          /linux/redhat
  92.        ftp.msu.ru              /pub/Linux/RedHat
  93.        linux.ucs.indiana.edu   /pub/linux/redhat
  94.        ftp.cvut.cz             /pub/linux/redhat
  95.        ftp.ton.tut.fi          /pub/Linux/RedHat
  96.        ftp.funet.fi            /pub/Linux/images/RedHat
  97.  
  98.  
  99.  
  100.  
  101.   We are unsure at this point where to find it past there, but it will
  102.   most likely just be a directory called RPM.  We will make a tar file
  103.   available with a README containing all the install instructions you
  104.   should need.
  105.  
  106.  
  107.   3.2.  RPM Requirements
  108.  
  109.   The main requirement to run RPM is Perl 5.x.  All of RPM is written in
  110.   Perl.  You must also have a working copy of cpio and gunzip, which
  111.   most Linux distributions have now.  While this system is intended for
  112.   use with Linux, it may very well be portable to other Unix systems who
  113.   meet the above conditions.  Be warned, the binary packages generated
  114.   on a different type of Unix system will not be compatible.
  115.  
  116.   Those are the minimal requirements to install RPMs.  To build RPMs
  117.   from source, you also need everything normally required to build a
  118.   package, like gcc, make, etc.
  119.  
  120.  
  121.  
  122.   4.  Using RPM
  123.  
  124.   In its simplest form, RPM can be used to install packages:
  125.  
  126.  
  127.                rpm -i foobar-1.0-1.i386.rpm
  128.  
  129.  
  130.  
  131.  
  132.   The next simplest command is to uninstall a package:
  133.                rpm -u foobar
  134.  
  135.  
  136.  
  137.  
  138.   One of the more complex but highly useful commands allows you to
  139.   install packages via FTP.  If you are connected to the net and want to
  140.   install a new package, all you need to do is specify the file with a
  141.   valid URL, like so:
  142.  
  143.  
  144.                rpm -i ftp://ftp.pht.com/pub/linux/redhat/rh-2.0-beta/RPMS/foobar-1.0-1.i386.rpm
  145.  
  146.  
  147.  
  148.  
  149.   Please note, however, that the current version of RPM will only do
  150.   installs via FTP.  You cannot run any of the more complex query
  151.   options on packages at an FTP site.
  152.  
  153.   While these are simple commands, rpm can be used in a multitude of
  154.   ways as seen from the Usage message:
  155.  
  156.  
  157.        rpm version 1.4.5
  158.        Copyright (C) 1995 - Red Hat Software
  159.        This may be freely redistributed under the terms of the GNU Public License
  160.  
  161.        usage: rpm {--help}
  162.               rpm {--version}
  163.               rpm {--install -i} [-v] [--hash -h] [--percent] [--force] [--test]
  164.                                  [--search] [--root <dir>] file1.rpm ... filen.rpm
  165.               rpm {--upgrade -U} [-v] [--hash -h] [--percent] [--force] [--test]
  166.                                  [--search] [--root <dir>] file1.rpm ... fileN.rpm
  167.               rpm {--query -q} [-afFpP] [-i] [-l] [-s] [-d] [-c] [-v]
  168.                                [--root <dir>] [targets]
  169.               rpm {--verify -V -y] [-afFpP] [--root <dir>] [targets]
  170.               rpm {--uninstall -u] [--root <dir>] package1 package2 ... packageN
  171.               rpm {-b}[plciba] [-v] [--short-circuit] [--clean] [--keep-temps]
  172.                                [--test] [--time-check <s>] specfile
  173.               rpm {--rebuild} [-v] source1.rpm source2.rpm ... sourceN.rpm
  174.               rpm {--where} package1 package2 ... packageN
  175.  
  176.  
  177.  
  178.  
  179.   First, I'll go through a synopsis of what all the options mean (don't
  180.   worry, there may be alot of options, but we tried to make them all as
  181.   intuitive as possible).
  182.  
  183.   Options are nested, so the possible options are many.  Here's a
  184.   description in parallel with the Usage message:
  185.  
  186.   o  help prints the usage message
  187.  
  188.   o  -i installs an rpm file.
  189.  
  190.   o  --hash, -h is a very cool option for watching the package install
  191.      (much like 'hash' in ftp).
  192.  
  193.   o  --percent prints the percentages as a package installs (but is only
  194.      useful for interfacing with other tools...is not really human
  195.      readable).
  196.  
  197.   o  --force will force an install of a binary package even though it
  198.      may already exist in the database.
  199.   o  --test will tell you if installing would work or not (do you have a
  200.      conflict with an already installed package).
  201.  
  202.   o  --root will install a package using the root prefix specified
  203.      instead of using the default of /.
  204.  
  205.   o  --install installs an rpm file.
  206.  
  207.   o  -U upgrades a package.  This option installs the new package and
  208.      then uninstalls the old one without hurting the new one.  The
  209.      upgrade option takes the same options as the install option.
  210.  
  211.   o  -q is the query option.  In its simplest form, you can do rpm -q
  212.      foobar which would return foobar-1.0-1.  (1.0 is the version
  213.      number, 1 is the release number.)
  214.  
  215.   o  Several options may be used with -q:
  216.  
  217.   o  -a will query all currently installed packages.
  218.  
  219.   o  -f <file> will query the package owning <file>.
  220.  
  221.   o  -F is the same as -f except you can give it filenames via stdin
  222.      (ie. ls /usr/bin | rpm -qF).
  223.  
  224.   o  -p <packagefile> will query the package.  It is really only useful
  225.      when combined with one of the Information Selection Options below.
  226.  
  227.   o  -P is like -p, except it takes its package filenames from stdin
  228.      (ie. ls /mnt/redhat/redhat-2.0/RPMS | rpm -qP).
  229.  
  230.   o  --root will query a mounted filesystem.
  231.  
  232.   o  Several Information Selection Options can be used with any
  233.      combination of the above options.  If none is given, the package
  234.      name only is displayed.
  235.  
  236.   o  -i displays package information such as Name, Description, Release,
  237.      etc.
  238.  
  239.   o  -l will display the file list from the entire package (all files
  240.      that get installed).  You can also use a -v with this to make the
  241.      file list much more verbose.
  242.  
  243.   o  -s shows you the state of all the files in the package.  There are
  244.      only two possible states, normal and missing.
  245.  
  246.   o  -d outputs a list of just the files marked as documentation (man
  247.      pages, info pages, READMEs, etc).  -v will give even more info.
  248.  
  249.   o  -c outputs a list of only the configuration files (sendmail.cf,
  250.      passwd, inittab, etc.) -v will give more info about the files.
  251.  
  252.   o  {-V,-y,--verify} are the verify options.  All are interchangeable.
  253.      They all take the same Package Specification and Information
  254.      Selection options as the -q option.  I'll list some examples:
  255.  
  256.   o  To verify a package containing particular file, do:
  257.  
  258.  
  259.        rpm -yf /bin/vi
  260.  
  261.  
  262.  
  263.  
  264.  
  265.   o  To verify ALL your files, do:
  266.  
  267.  
  268.        rpm -ya
  269.  
  270.  
  271.  
  272.  
  273.   o  To verify files on your system versus the files in a .rpm file, do:
  274.  
  275.  
  276.        rpm -Vp foobar-1.0-1.rpm
  277.  
  278.  
  279.  
  280.  
  281.   o  --uninstall, -u <package> to uninstall a package
  282.  
  283.   o  -b to build a package (from sources and a spec file).  This option
  284.      will be discussed more at length in the next section, Building
  285.      RPMs.
  286.  
  287.   o  -v be verbose in the output of what's going on.
  288.  
  289.   o  -vv be very verbose in the output of what's going on.
  290.  
  291.  
  292.   5.  Now what can I really do with RPM?
  293.  
  294.   RPM is a very useful tool and, as you can see, has several options.
  295.   The best way to make sense of them is to look at some examples.  I
  296.   covered simple install/uninstall above, so here are some more
  297.   examples:
  298.  
  299.   o  Let's say you delete some files by accident, but you aren't sure
  300.      what you deleted.  If you want to verify your entire system and see
  301.      what might be missing, you would do:
  302.  
  303.  
  304.        rpm -Va
  305.  
  306.  
  307.  
  308.  
  309.   o  Let's say you run across a file that you don't recognize.  To find
  310.      out which package owns it, you would do:
  311.  
  312.  
  313.        rpm -qf /usr/X11R6/bin/xjewel
  314.  
  315.  
  316.  
  317.  
  318.   The output would be:
  319.  
  320.  
  321.        xjewel-1.6-1
  322.  
  323.  
  324.  
  325.  
  326.   o  You find a new koules RPM, but you don't know what it is.  To find
  327.      out some information on it, do:
  328.  
  329.  
  330.  
  331.   rpm -qpi koules-1.0-1.i386.rpm
  332.  
  333.  
  334.  
  335.  
  336.   The output would be:
  337.  
  338.  
  339.        Name        : koules                      Distribution: RHCL 2.0
  340.        Version     : 1.0                               Vendor: Red Hat Software
  341.        Release     : 1                             Build date: Tue Aug 29 12:53:21 1995
  342.        Install date: <not installed>               Build host: daffy.redhat.com
  343.        Group       : Games
  344.        Size        : 403105
  345.        Description : well done SVGAlib game
  346.  
  347.  
  348.  
  349.  
  350.   o  Now you want to see what files the koules RPM installs.  You would
  351.      do:
  352.  
  353.  
  354.        rpm -qpl koules-1.0-1.i386.rpm
  355.  
  356.  
  357.  
  358.  
  359.   The output is:
  360.  
  361.  
  362.        /usr/man/man6/koules.6
  363.        /usr/lib/games/kouleslib/start.raw
  364.        /usr/lib/games/kouleslib/end.raw
  365.        /usr/lib/games/kouleslib/destroy2.raw
  366.        /usr/lib/games/kouleslib/destroy1.raw
  367.        /usr/lib/games/kouleslib/creator2.raw
  368.        /usr/lib/games/kouleslib/creator1.raw
  369.        /usr/lib/games/kouleslib/colize.raw
  370.        /usr/lib/games/kouleslib
  371.        /usr/games/koules
  372.  
  373.  
  374.  
  375.  
  376.   These are just several examples.  More creative ones can be thought of
  377.   really easy once you are familiar with RPM.
  378.  
  379.  
  380.  
  381.   6.  Building RPMs
  382.  
  383.  
  384.   Building RPMs is fairly easy to do, especially if you can get the
  385.   software you are trying to package to build on its own.
  386.  
  387.   The basic procedure to build an RPM is as follows:
  388.  
  389.   o  Make sure your /etc/rpmrc is setup for your system.
  390.  
  391.   o  Get the source code you are building the RPM for to build on your
  392.      system.
  393.  
  394.   o  Make a patch of any changes you had to make to the sources to get
  395.      them to build properly.
  396.  
  397.   o  Make a spec file for the package.
  398.  
  399.   o  Make sure everything is in its proper place.
  400.  
  401.   o  Build the package using RPM.
  402.  
  403.   Under normal operation, RPM builds both binary and source packages.
  404.  
  405.  
  406.  
  407.  
  408.   6.1.  The rpmrc File
  409.  
  410.  
  411.   Right now, the only configuration of RPM is available via the
  412.   /etc/rpmrc file.  An example one looks like:
  413.  
  414.  
  415.        require_vendor: 1
  416.        require_distribution: 1
  417.        require_group: 1
  418.        distribution: RHCL 2.0
  419.        vendor: Red Hat Software
  420.        arch_sensitive: 1
  421.        topdir: /usr/src/redhat-2.0
  422.  
  423.        optflags: i386 -O2 -m486
  424.        optflags: axp -O2
  425.  
  426.  
  427.  
  428.  
  429.   The require_vendor line causes RPM to require that it find a vendor
  430.   line.  This can come from the /etc/rpmrc or from the header of the
  431.   spec file itself.  To turn this off, change the number to 0.  The same
  432.   holds true for the require_distribution and require_group lines.
  433.  
  434.   The next line is the distribution line.  You can define that here or
  435.   later in the header of the spec file.  When building for a particular
  436.   distribution, it's a good idea to make sure this line is correct, even
  437.   though it is not required.  The vendor  line works much the same way,
  438.   but can be anything (ie. Joe's Software and Rock Music Emporium).
  439.  
  440.   The next line is arch_sensitive.  This specifies where the binary RPMs
  441.   go and what they are named.  Right now, i386 is defined as a type
  442.   within RPM.  That means if you are building on an Intel machine and
  443.   have this value set to true, your RPMs will go in
  444.   /usr/src/redhat-2.0/RPMS/i386/ and their name will be something like
  445.   foobar-1.0-1.i386.rpm.  If you set this value to 0, the RPMs will be
  446.   placed in /usr/src/redhat-2.0/RPMS/ and will be named something like
  447.   foobar-1.0-1.bin.rpm.  This does not affect the name or placement of
  448.   the source RPM, however.
  449.  
  450.   RPM also now has support for building packages on multiple
  451.   architectures.  The rpmrc file can hold an ``optflags'' variable for
  452.   building things that require architecture specific flags when
  453.   building.  See later sections for how to use this variable.
  454.  
  455.   In addition to the above macros, there are several more.  You can use:
  456.  
  457.   o  topdir to specify the top level directory for building.  In Red Hat
  458.      2.0, this directory is /usr/src/redhat-2.0.
  459.  
  460.   o  specdir is the directory under topdir to use for the spec files.
  461.      The default for this is SPECS.
  462.  
  463.   o   builddir specifies the top level of the build directory.  The
  464.      default for this is BUILD.
  465.  
  466.   o  sourcedir specifies the top level of the source directory.  The
  467.      default for this is SOURCES.  This is where the pristine tar files,
  468.      the patches, and the icons go.
  469.  
  470.   o  rpmdir sets the directory for the binary RPMs.  The default for
  471.      this is RPMS.
  472.  
  473.   o  srcrpmdir sets the directory for the source RPMs.  The default for
  474.      this is SRPMS.
  475.  
  476.   o  docdir specifies where the documentation should be installed.  By
  477.      default, this is /usr/doc.
  478.  
  479.   o  libdir sets the path for the RPM database.  By default, this is
  480.      /var/lib/rpm.
  481.  
  482.   o  timecheck sets whether or not to do a timecheck by default.
  483.  
  484.  
  485.   6.2.  The Spec File
  486.  
  487.   We'll begin with discussion of the spec file.  Spec files are required
  488.   to build a package.  The spec file is a description of the software
  489.   along with instructions on how to build it and a file list for all the
  490.   binaries that get installed.
  491.  
  492.   You'll want to name your spec file according to a standard convention.
  493.   It should be the package name-dash-version number-dash-release number-
  494.   dot-spec.
  495.  
  496.   Here is a small spec file (vim-3.0-1.spec):
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.   Description: VIsual editor iMproved
  530.   Name: vim
  531.   Version: 3.0
  532.   Release: 1
  533.   Icon: vim.gif
  534.   Source: sunsite.unc.edu:/pub/Linux/apps/editors/vi/vim-3.0.tar.gz
  535.   Patch: vim-3.0-make.patch
  536.   Copyright: distributable
  537.   Group: Applications/Editors
  538.  
  539.   %prep
  540.   %setup
  541.   %patch -p1
  542.   cd src
  543.   cp makefile.unix makefile
  544.  
  545.   %build
  546.   cd src
  547.   make
  548.  
  549.   %install
  550.   rm -f /bin/vim
  551.   cd src
  552.   make install
  553.   ln -sf vim /bin/vi
  554.  
  555.   %files
  556.   %doc doc/reference.doc doc/unix.doc tutor/tutor
  557.   /bin/vim
  558.   /bin/vi
  559.   /usr/man/man1/vim.1
  560.   /usr/lib/vim.hlp
  561.  
  562.  
  563.  
  564.  
  565.  
  566.   6.3.  The Header
  567.  
  568.   The header has some standard fields in it that you need to fill in.
  569.   There are a few caveats as well.  The fields must be filled in as
  570.   follows:
  571.  
  572.   o  Description: This one is kind of obvious.  You can span multiple
  573.      lines by ending each line with a backslash.
  574.  
  575.   o  Name: This must be the name string from the rpm filename you plan
  576.      to use.
  577.  
  578.   o  Version: This must be the version string from the rpm filename you
  579.      plan to use.
  580.  
  581.   o  Release: This is the release number for a package of the same
  582.      version (ie. if we make a package and find it to be slightly broken
  583.      and need to make it again, the next package would be release number
  584.      2).
  585.  
  586.   o  Icon: This is the name of the icon file for use by other high level
  587.      installation tools (like Red Hat's ``glint'').  It must be a gif
  588.      and resides in the SOURCES directory.
  589.  
  590.   o  Source: This line points at the HOME location of the pristine
  591.      source file.  It is used if you ever want to get the source again
  592.      or check for newer versions.  Caveat:  The filename in this line
  593.      MUST match the filename you have on your own system (ie. don't
  594.      download the source file and change its name).  You can also
  595.      specify more than one source file using lines like:
  596.  
  597.  
  598.        Source0: blah-0.tar.gz
  599.        Source1: blah-1.tar.gz
  600.        Source2: fooblah.tar.gz
  601.  
  602.  
  603.  
  604.  
  605.   These files would go in the SOURCES directory. (The directory struc-
  606.   ture is discussed in a later section, "The Source Directory Tree".)
  607.  
  608.   o  Patch: This is the place you can find the patch if you need to
  609.      download it again.  Caveat:  The filename here must match the one
  610.      you use when you make YOUR patch.  You may also want to note that
  611.      you can have multiple patch files much as you can have multiple
  612.      sources.  ] You would have something like:
  613.  
  614.  
  615.        Patch0: blah-0.patch
  616.        Patch1: blah-1.patch
  617.        Patch2: fooblah.patch
  618.  
  619.  
  620.  
  621.  
  622.   These files would go in the SOURCES directory.
  623.  
  624.   o  Copyright: This line tells how a package is copyrighted.  You
  625.      should use something like GPL, BSD, MIT, public domain,
  626.      distributable, or commercial.
  627.  
  628.   o  Root: This line allows you to specify a directory as the ``root''
  629.      for building and installing the new package.  You can use this to
  630.      help test your package before having it installed on your machine.
  631.  
  632.   o  Group: This line is used to tell high level installation programs
  633.      (such as Red Hat's ``glint'') where to place this particular
  634.      program in its hierarchical structure.  The group tree currently
  635.      looks something like this:
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.   Applications
  662.       Communications
  663.       Editors
  664.           Emacs
  665.       Engineering
  666.       Spreadsheets
  667.       Databases
  668.       Graphics
  669.       Networking
  670.       Mail
  671.       Math
  672.       News
  673.       Publishing
  674.           TeX
  675.   Base
  676.       Kernel
  677.   Utilities
  678.       Archiving
  679.       Console
  680.       File
  681.       System
  682.       Terminal
  683.       Text
  684.   Daemons
  685.   Documentation
  686.   X11
  687.       XFree86
  688.           Servers
  689.       Applications
  690.           Graphics
  691.           Networking
  692.       Games
  693.           Strategy
  694.           Video
  695.       Amusements
  696.       Utilities
  697.       Libraries
  698.       Window Managers
  699.   Libraries
  700.   Networking
  701.       Admin
  702.       Daemons
  703.       News
  704.       Utilities
  705.   Development
  706.       Debuggers
  707.       Libraries
  708.           Libc
  709.       Languages
  710.           Fortran
  711.           Tcl
  712.       Building
  713.       Version Control
  714.       Tools
  715.   Shells
  716.   Games
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.   6.4.  Prep
  724.  
  725.   This is the second section in the spec file.  It is used to get the
  726.   sources ready to build.  Here you need to do anything necessary to get
  727.   the sources patched and setup like they need to be setup to do a make.
  728.  
  729.   One thing to note:  Each of these sections is really just a place to
  730.   execute shell scripts.  You could simply make an sh script and put it
  731.   after the %prep tag to unpack and patch your sources.  We have made
  732.   macros to aid in this, however.
  733.  
  734.   The first of these macros is the %setup macro.  In its simplest form
  735.   (no command line options), it simply unpacks the sources and cd's into
  736.   the source directory.  It also takes the following options:
  737.  
  738.  
  739.   o  -n name will set the name of the build directory to the listed
  740.      name.  The default is $NAME-$VERSION.  Other possibilities include
  741.      $NAME, ${NAME}${VERSION}, or whatever the main tar file uses.
  742.  
  743.   o  -c will create and cd to the named directory before doing the
  744.      untar.
  745.  
  746.   o  -b # will untar Source# before cd'ing into the directory (and this
  747.      makes no sense with -c so don't do it).  This is only useful with
  748.      multiple source files.
  749.  
  750.   o  -a # will untar Source# after cd'ing into the directory.
  751.  
  752.   o  -T This option overrides the default action of untarring the Source
  753.      and requires a -b 0 or -a 0 to get the main source file untarred.
  754.      You need this when there are secondary sources.
  755.  
  756.   o  -D Do not delete the directory before unpacking.  This is only
  757.      useful where you have more than one setup macro.  It should only be
  758.      used in setup macros after the first one (but never in the first
  759.      one).
  760.  
  761.   The next of the available macros is the %patch macro.  This macro
  762.   helps automate the process of applying patches to the sources.  It
  763.   takes several options, listed below:
  764.  
  765.   o  # will apply Patch# as the patch file.
  766.  
  767.   o  -p # specifies the number of directories to strip for the patch(1)
  768.      command.
  769.  
  770.   o  -P The default action is to apply Patch (or Patch0).  This flag
  771.      inhibits the default action and will require a 0 to get the main
  772.      source file untarred.  This option is useful in a second (or later)
  773.      %patch macro that required a different number than the first macro.
  774.  
  775.   o  You can also do %patch# instead of doing the real command: %patch #
  776.      -P
  777.  
  778.   That should be all the macros you need.  After you have those right,
  779.   you can also do any other setup you need to do via sh type scripting.
  780.   Anything you include up until the %build macro (discussed in the next
  781.   section) is executed via sh.  Look at the example above for the types
  782.   of things you might want to do here.
  783.  
  784.  
  785.   6.5.  Build
  786.  
  787.   There aren't really any macros for this section.  You should just put
  788.   any commands here that you would need to use to build the software
  789.   once you had untarred the source, patched it, and cd'ed into the
  790.   directory.  This is just another set of commands passed to sh, so any
  791.   legal sh commands can go here (including comments).  Your current
  792.   working directory is reset in each of these sections to the toplevel
  793.   of the source directory, so keep that in mind.  You can cd into
  794.   subdirectories if necessary.
  795.  
  796.  
  797.   6.6.  Install
  798.  
  799.   There aren't really any macros here, either.  You basically just want
  800.   to put whatever commands here that are necessary to install.  If you
  801.   have make install available to you in the package you are building,
  802.   put that here.  If not, you can either patch the makefile for a make
  803.   install and just do a make install here, or you can hand install them
  804.   here with sh commands.  You can consider your current directory to be
  805.   the toplevel of the source directory.
  806.  
  807.  
  808.   6.7.  Optional pre and post Install/Uninstall Scripts
  809.  
  810.   You can put scripts in that get run before and after the installation
  811.   and uninstallation of binary packages.  A main reason for this is to
  812.   do things like run ldconfig after installing or removing packages that
  813.   contain shared libraries.  The macros for each of the scripts is as
  814.   follows:
  815.  
  816.   o  %pre is the macro to do pre-install scripts.
  817.  
  818.   o  %post is the macro to do post-install scripts.
  819.  
  820.   o  %preun is the macro to do pre-uninstall scripts.
  821.  
  822.   o  %postun is the macro to do post-uninstall scripts.
  823.  
  824.   The contents of these sections should just be any sh style script,
  825.   though you do not need the #!/bin/sh.
  826.  
  827.  
  828.   6.8.  Files
  829.  
  830.   This is the section where you must list the files for the binary
  831.   package.  RPM has no way to know what binaries get installed as a
  832.   result of make install.  There is NO way to do this.  Some have
  833.   suggested doing a find before and after the package install.  With a
  834.   multiuser system, this is unacceptable as other files may be created
  835.   during a package building process that have nothing to do with the
  836.   package itself.
  837.  
  838.   There are some macros available to do some special things as well.
  839.   They are listed and described here:
  840.  
  841.   o  %doc is used to mark documentation in the source package that you
  842.      want installed in a binary install.  The documents will be
  843.      installed in /usr/doc/$NAME-$VERSION-$RELEASE.  You can list
  844.      multiple documents on the command line with this macro, or you can
  845.      list them all separately using a macro for each of them.
  846.  
  847.   o  %config is used to mark configuration files in a package.  This
  848.      includes files like sendmail.cf, passwd, etc.  If you later
  849.      uninstall a package containing config files, any unchanged files
  850.      will be removed and any changed files will get moved to their old
  851.      name with a .rpmsave appended to the filename.  You can list
  852.      multiple files with this macro as well.
  853.  
  854.   o  %dir marks a single directory in a file list to be included as
  855.      being owned by a package.  By default, if you list a directory name
  856.      WITHOUT a %dir macro, EVERYTHING in that directory is included in
  857.      the file list and later installed as part of that package.
  858.  
  859.   The biggest caveat in the file list is listing directories.  If you
  860.   list /usr/bin by accident, your binary package will contain every file
  861.   in /usr/bin on your system.
  862.  
  863.  
  864.   6.9.  Building It
  865.  
  866.  
  867.   6.9.1.  The Source Directory Tree
  868.  
  869.   The first thing you need is a properly configured build tree.  This is
  870.   configurable using the /etc/rpmrc file.  Most people will just use
  871.   /usr/src.
  872.  
  873.   You may need to create the following directories to make a build tree:
  874.  
  875.   o  BUILD is the directory where all building occurs by RPM.  You don't
  876.      have to do your test building anywhere in particular, but this is
  877.      where RPM will do it's building.
  878.  
  879.   o  SOURCES is the directory where you should put your original source
  880.      tar files and your patches.  This is where RPM will look by
  881.      default.
  882.  
  883.   o  SPECS is the directory where all spec files should go.
  884.  
  885.   o  RPMS is where RPM will put all binary RPMs when built.
  886.  
  887.   o  SRPMS is where all source RPMs will be put.
  888.  
  889.  
  890.   6.9.2.  Test Building
  891.  
  892.   The first thing you'll probably want to to is get the source to build
  893.   cleanly without using RPM.  To do this, unpack the sources, and change
  894.   the directory name to $NAME.orig.  Then unpack the source again.  Use
  895.   this source to build from.  Go into the source directory and follow
  896.   the instructions to build it.  If you have to edit things, you'll need
  897.   a patch.  Once you get it to build, clean the source directory.  Make
  898.   sure and remove any files that get made from a ./configure.  Then cd
  899.   back out of the source directory to its parent.  Then you'll do
  900.   something like:
  901.  
  902.  
  903.                diff -uNr dirname.orig dirname > ../SOURCES/dirname-linux.patch
  904.  
  905.  
  906.  
  907.  
  908.   This will create a patch for you that you can use in your spec file.
  909.   Note that the ``linux'' that you see in the patch name is just an
  910.   identifier.  You might want to use something more descriptive like
  911.   ``config'' or ``bugs'' to describe why you had to make a patch.  It's
  912.   also a good idea to look at the patch file you are creating before
  913.   using it to make sure no binaries were included by accident.
  914.  
  915.  
  916.   6.9.3.  Generating the File List
  917.  
  918.   Now that you have source that will build and you know how to do it,
  919.   build it and install it.  Look at the output of the install sequence
  920.   and build your file list from that to use in the spec file.  We
  921.   usually build the spec file in parallel with all of these steps.  You
  922.   can create the initial one and fill in the easy parts, and then fill
  923.   in the other steps as you go.
  924.  
  925.   6.9.4.  Building the Package with RPM
  926.  
  927.   Once you have a spec file, you are ready to try and build your
  928.   package.  The most useful way to do it is with a command like the
  929.   following:
  930.  
  931.  
  932.  
  933.                rpm -ba -v foobar-1.0.spec
  934.  
  935.  
  936.  
  937.  
  938.   There are other options useful with the -b switch as well:
  939.  
  940.   o  p means just run the prep section of the specfile.
  941.  
  942.   o  l is a list check that does some checks on %files.
  943.  
  944.   o  c do a prep and compile.  This is useful when you are unsure of
  945.      whether your source will build at all.  It seems useless because
  946.      you might want to just keep playing with the source itself until it
  947.      builds and then start using RPM, but once you become accustomed to
  948.      using RPM you will find instances when you will use it.
  949.  
  950.   o  i do a prep, compile, and install.
  951.  
  952.   o  b prep, compile, install, and build a binary package only.
  953.  
  954.   o  a build it all (both source and binary packages).
  955.  
  956.      There are several modifiers to the -b switch.  They are as follows:
  957.  
  958.   o  --short-circuit will skip straight to a specified stage (can only
  959.      be used with c and i).
  960.  
  961.   o  --clean removes the build tree when done.
  962.  
  963.   o  --keep-temps will keep all the temp files and scripts that were
  964.      made in /tmp.  You can actually see what files were created in /tmp
  965.      using the -v option.
  966.  
  967.   o  --test does not execute any real stages, but does keep-temp.
  968.  
  969.   o  --time-check # is very useful.  By default, the time-check value is
  970.      7200 seconds (two hours).  What this does is check all the files in
  971.      %files and warns you if they are more than # seconds old (or the
  972.      default).  This lets you make sure that the newly created binaries
  973.      are getting installed and not old ones that just happen to be still
  974.      lying around.  This author can attest to the value of this feature
  975.      after having to release several RPP updates because old binaries
  976.      were accidentally included.  You can also turn this off (useful
  977.      when building binary only packages of commercial software) by
  978.      setting the value to zero.
  979.  
  980.  
  981.   6.10.  Testing It
  982.  
  983.   Once you have a source and binary rpm for your package, you need to
  984.   test it.  The easiest and best way is to use a totally different
  985.   machine from the one you are building on to test.  After all, you've
  986.   just done a lot of make install's on your own machine, so it should be
  987.   installed fairly well.
  988.  
  989.   You can do an rpm -u packagename on the package to test, but that can
  990.   be deceiving because in building the package, you did a make install.
  991.   If you left something out of your file list, it will not get
  992.   uninstalled.  You'll then reinstall the binary package and your system
  993.   will be complete again, but your rpm still isn't.  Make sure and keep
  994.   in mind that just because you do a rpm -ba package, most people
  995.   installing your package will just be doing the rpm -i package.  Make
  996.   sure you don't do anything in the build or install sections that will
  997.   need to be done when the binaries are installed by themselves.
  998.  
  999.  
  1000.  
  1001.   6.11.  What to do with your new RPMs
  1002.  
  1003.   Once you've made your own RPM of something (assuming its something
  1004.   that hasn't already been RPM'ed), you can contribute your work to
  1005.   others (also assuming you RPM'ed something freely distributable).  To
  1006.   do so, you'll want to upload it to an FTP site somewhere.  We hope RPM
  1007.   will become a standard that everyone starts using.  If that is the
  1008.   case, you should probably upload your RPMs to sunsite.unc.edu.  Until
  1009.   then, please upload them to our official Red Hat Mirror,
  1010.   ftp.pht.com:/pub/linux/redhat/Incoming.  We are currently mirrored on
  1011.   several other sites, and this is the best place to find new RPMs.
  1012.  
  1013.  
  1014.  
  1015.   7.  Advanced RPM Building
  1016.  
  1017.   RPM has some very advanced features available for larger, more complex
  1018.   packages.  It has the ability to build and output multiple binary
  1019.   subpackages.  An example of this is the ability to produce separate
  1020.   Tcl/Tk binary packages from one spec file.  Another example is the
  1021.   ability to use one spec file to create a single XFree86 package with
  1022.   no servers, and a separate package for each of the servers.
  1023.  
  1024.  
  1025.   7.1.  How to Get Started
  1026.  
  1027.   The best way to get started is to look at an example spec file.  The
  1028.   following tcl/tk spec file is a good one to start with (though you can
  1029.   also view the spec file of any package by installing the sources and
  1030.   looking in /usr/src/redhat-2.0/SPECS):
  1031.  
  1032.  
  1033.  
  1034.  
  1035.  
  1036.  
  1037.  
  1038.  
  1039.  
  1040.  
  1041.  
  1042.  
  1043.  
  1044.  
  1045.  
  1046.  
  1047.  
  1048.  
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.   %package tcl
  1058.   Description: Tool Command Language
  1059.   Name: tcltk
  1060.   Version: 7.4_4.0
  1061.   Release: 1
  1062.   Icon: tcl.gif
  1063.   Source0: ftp.cs.berkeley.com:/pub/tcl/tcl7.4.tar.Z
  1064.   Source1: ftp.cs.berkeley.com:/pub/tcl/tk4.0.tar.Z
  1065.   Copyright: BSD
  1066.   Group: Development/Languages/Tcl
  1067.   Patch0: sunsite.unc.edu:/pub/Linux/devel/tcl7.4-1.diff.gz
  1068.   Patch1: sunsite.unc.edu:/pub/Linux/devel/tk4.0-1.diff.gz
  1069.   %package tk
  1070.   Icon: tk.gif
  1071.   Description: Tk toolkit
  1072.   Group: Development/Languages/Tcl
  1073.  
  1074.   %prep
  1075.   %setup -T -c -a 0
  1076.   %setup -T -D -a 1
  1077.   %patch0 -p0
  1078.   %patch1 -p0
  1079.  
  1080.   %build
  1081.   cd tcl7.4
  1082.   make
  1083.   cd ../tk4.0
  1084.   make
  1085.  
  1086.   %install
  1087.   cd tcl7.4
  1088.   make install
  1089.   ln -sf libtcl7.4.a /usr/lib/libtcl.a
  1090.   ln -sf libtcl7.4.so.1 /usr/lib/libtcl.so.1
  1091.   ln -sf libtk4.0.a /usr/lib/libtk.a
  1092.   ln -sf libtk4.0.so.1 /usr/lib/libtk.so.1
  1093.   cd ../tk4.0
  1094.   make install
  1095.  
  1096.   %post tcl
  1097.   /sbin/ldconfig
  1098.  
  1099.   %post tk
  1100.   /sbin/ldconfig
  1101.  
  1102.   %postun tcl
  1103.   /sbin/ldconfig
  1104.  
  1105.   %postun tk
  1106.   /sbin/ldconfig
  1107.  
  1108.   %files tcl
  1109.   /usr/lib/libtcl7.4.a
  1110.   /usr/lib/libtcl.a
  1111.   /usr/lib/libtcl7.4.so.1
  1112.   /usr/lib/libtcl.so.1
  1113.   /usr/include/tcl/tcl*
  1114.   /usr/bin/tclsh
  1115.   /usr/bin/tclsh7.4
  1116.   /usr/lib/tcl7.4
  1117.   /usr/man/man1/*tcl
  1118.   /usr/man/man3/*tcl
  1119.  
  1120.   %files tk
  1121.   /usr/lib/libtk4.0.a
  1122.   /usr/lib/libtk.a
  1123.   /usr/lib/libtk4.0.so.1
  1124.   /usr/lib/libtk.so.1
  1125.   /usr/include/tcl/ks_names.h
  1126.   /usr/include/tcl/default.h
  1127.   /usr/include/tcl/tk*
  1128.   /usr/lib/tk4.0
  1129.   /usr/man/man1/*tk
  1130.   /usr/man/man3/*tk
  1131.   /usr/bin/wish
  1132.   /usr/bin/wish4.0
  1133.  
  1134.  
  1135.  
  1136.  
  1137.  
  1138.   7.2.  Sub-Packages
  1139.  
  1140.   One of the main advanced features of RPM is the ability to build
  1141.   subpackages.  They are easy to build as for most macros you can just
  1142.   add the subpackage name as a parameter for anything specific to a
  1143.   subpackage (and if you leave it off the section will apply to the main
  1144.   package).
  1145.  
  1146.  
  1147.   7.3.  The Header
  1148.  
  1149.   The header only has one major difference, the %package macro.  This
  1150.   macro is used in the header to tell which subpackage name to match the
  1151.   description with.  If you omit the macro in the initial part of the
  1152.   header, you will get a main package with no change to the name.  In
  1153.   the XFree86 package, however, there is no %package macro in the top of
  1154.   the header.  This is because we wanted a base XFree86 package with all
  1155.   the common stuff in it and then several subpackages (XFree86-SVGA,
  1156.   etc.) with the servers.  Tcl/Tk does not need a main package, so the
  1157.   macro is at the top.
  1158.  
  1159.   Another difference is the fact that this package has multiple source
  1160.   and patch lines.  If you'll notice, there is now a Source0 line
  1161.   instead of just Source.  They are functionally equivalent, though it
  1162.   is a good idea to use Source0 when there is more than one source file
  1163.   (and the same applies to patches as well).
  1164.  
  1165.  
  1166.   7.4.  Prep
  1167.  
  1168.   Prep is basically the same as in the simple example, except it uses
  1169.   more of the options available to the setup and patch macros.
  1170.  
  1171.   7.5.  Build
  1172.  
  1173.   Build is basically the same, with the exception that the setup macro
  1174.   above used the -T option.  Because of that, you have to do a manual cd
  1175.   to get into the source directory.
  1176.  
  1177.   You will also notice that the build does a configure before it can
  1178.   build.  This is the section where any of this type of configuration
  1179.   should go.
  1180.  
  1181.   7.6.  Install
  1182.  
  1183.   Again, everything is pretty normal with the exception of the fact that
  1184.   you must manually cd into the source directories.
  1185.  
  1186.  
  1187.  
  1188.  
  1189.   7.7.  Optional pre and post Install/Uninstall Scripts
  1190.  
  1191.   This section is almost the same as in a simple RPM case (see the above
  1192.   section).  It has two post install scripts that run ldconfig for each
  1193.   of the subpackages upon install.  It should have two post uninstall
  1194.   scripts to run ldconfig as well.
  1195.  
  1196.  
  1197.   7.8.  Files
  1198.  
  1199.   Here you will declare which files go in which packages.  You really
  1200.   have multiple file sections, each started with a new %files macro and
  1201.   the name of the subpackage (except in the case where you have a main
  1202.   package...that %files macro will have no argument given to it).  The
  1203.   other macros (doc, config, etc) work exactly the same as in the simple
  1204.   case.
  1205.  
  1206.   You also have the option to use the * to glob filenames out of a
  1207.   directory.  You need to be careful with this (perhaps test it first)
  1208.   so as not to include files you didn't mean to.  The above example does
  1209.   this with the man pages.
  1210.  
  1211.  
  1212.   7.9.  What Now?
  1213.  
  1214.   Please see the above sections on Testing and What to do with new RPMs.
  1215.   We want all the RPMs available we can get, and we want them to be good
  1216.   RPMs.  Please take the time to test them well, and then take the time
  1217.   to upload them for everyone's benefit.  Also, please make sure you are
  1218.   only uploading freely available software.  Commercial software and
  1219.   shareware should not be uploaded unless they have a copyright
  1220.   expressly stating that this is allowed.
  1221.  
  1222.  
  1223.   8.  Multi-architectural RPM Building
  1224.  
  1225.   RPM can now be used to build packages for the Intel i386, the Digital
  1226.   Alpha running Linux, and the Sparc.  It has been reported to work on
  1227.   SGI's and HP workstations as well.  There are several features that
  1228.   make building packages on all platforms easy.  The first of these is
  1229.   the ``optflags'' directive in the /etc/rpmrc.  It can be used to set
  1230.   flags used when building software to architecture specific values.
  1231.   Another feature is the ``arch'' macros in the spec file.  They can be
  1232.   used to do different things depending on the architecture you are
  1233.   building on.  Another feature is the ``Exclude'' directive in the
  1234.   header.
  1235.  
  1236.  
  1237.   8.1.  Sample spec File
  1238.  
  1239.   The following is the spec file for the ``zoneinfo'' package.  It is
  1240.   setup to build on both the Alpha and the Intel.
  1241.  
  1242.  
  1243.  
  1244.  
  1245.  
  1246.  
  1247.  
  1248.  
  1249.  
  1250.  
  1251.  
  1252.  
  1253.  
  1254.  
  1255.   Description: Time zone utilities and data
  1256.   Name: zoneinfo
  1257.   Version: 95e
  1258.   Release: 2
  1259.   Copyright: Distributable
  1260.   Group: Utilities/System
  1261.   Source0: elsie.nci.nih.gov:/pub/tzcode95e.tar.gz
  1262.   Source1: elsie.nci.nih.gov:/pub/tzdata95i.tar.gz
  1263.   Patch0: zoneinfo-95e-make.patch
  1264.   Patch1: zoneinfo-95e-64bit.patch
  1265.  
  1266.   %prep
  1267.   %setup -c -a 1
  1268.   %patch0 -p1
  1269.  
  1270.   %ifarch axp
  1271.   %patch1 -p1
  1272.   %endif
  1273.  
  1274.   %build
  1275.   make RPM_OPT_FLAGS="${RPM_OPT_FLAGS}"
  1276.  
  1277.   %install
  1278.   rm -rf /usr/lib/zoneinfo
  1279.  
  1280.   make install
  1281.  
  1282.   rm -f /usr/lib/zoneinfo/localtime /usr/lib/zoneinfo/posixrules /usr/lib/zoneinfo/posixtime
  1283.   ln -sf ../../../etc/localtime /usr/lib/zoneinfo/localtime
  1284.   ln -sf localtime /usr/lib/zoneinfo/posixrules
  1285.   ln -sf localtime /usr/lib/zoneinfo/posixtime
  1286.  
  1287.   strip /usr/sbin/zic /usr/sbin/zdump
  1288.  
  1289.   %files
  1290.   %doc README Theory
  1291.   /usr/lib/zoneinfo
  1292.   /usr/lib/libz.a
  1293.   /usr/sbin/zic
  1294.   /usr/sbin/zdump
  1295.   /usr/man/man3/newctime.3
  1296.   /usr/man/man3/newtzset.3
  1297.   /usr/man/man5/tzfile.5
  1298.   /usr/man/man8/zdump.8
  1299.   /usr/man/man8/zic.8
  1300.  
  1301.  
  1302.  
  1303.  
  1304.  
  1305.   8.2.  Optflags
  1306.  
  1307.   In this example, you see how the ``optflags'' directive is used from
  1308.   the /etc/rpmrc.  Depending on which architecture you are building on,
  1309.   the proper value is given to RPM_OPT_FLAGS.  You must patch the
  1310.   Makefile for your package to use this variable in place of the normal
  1311.   directives you might use (like -m486 and -O2).  You can get a better
  1312.   feel for what needs to be done by installing this source package and
  1313.   then unpacking the source and examine the Makefile.  Then look at the
  1314.   patch for the Makefile and see what changes must be made.
  1315.  
  1316.  
  1317.   8.3.  Macros
  1318.  
  1319.   The %ifarch macro is very important to all of this.  Most times you
  1320.   will need to make a patch or two that is specific to one architecture
  1321.   only.  In this case, RPM will allow you to apply that patch to just
  1322.   one architecture only.
  1323.  
  1324.   In the above example, zoneinfo has a patch for 64 bit machines.
  1325.   Obviously, this should only be applied on the Alpha at the moment.
  1326.   So, we add an %ifarch macro around the 64 bit patch like so:
  1327.  
  1328.  
  1329.        %ifarch axp
  1330.        %patch1 -p1
  1331.        %endif
  1332.  
  1333.  
  1334.  
  1335.  
  1336.   This will insure that the patch is not applied on any architecture
  1337.   except the alpha.
  1338.  
  1339.  
  1340.   8.4.  Excluding Architectures from Packages
  1341.  
  1342.   So that you can maintain source RPMs in one directory for all
  1343.   platforms, we have implemented the ability to ``exclude'' packages
  1344.   from being built on certain architectures.  This is so you can still
  1345.   do things like
  1346.  
  1347.  
  1348.        rpm --rebuild /usr/src/SRPMS/*.rpm
  1349.  
  1350.  
  1351.  
  1352.  
  1353.   and have the right packages build.  If you haven't yet ported an
  1354.   application to a certain platform, all you have to do is add a line
  1355.   like:
  1356.  
  1357.  
  1358.        Exclude: axp
  1359.  
  1360.  
  1361.  
  1362.  
  1363.   to the header of the spec file of the source package.  Then rebuild
  1364.   the package on the platform that it does build on.  You'll then have a
  1365.   source package that builds on an Intel and can easily be skipped on an
  1366.   Alpha.
  1367.  
  1368.  
  1369.   8.5.  Finishing Up
  1370.  
  1371.   Using RPM to make multi-architectural packages is usually easier to do
  1372.   than getting the package itself to build both places.  As more of the
  1373.   hard packages get built this is getting much easier, however.  As
  1374.   always, the best help when you get stuck building an RPM is to look a
  1375.   similar source package.
  1376.  
  1377.  
  1378.  
  1379.  
  1380.   9.  Copyright Notice
  1381.  
  1382.   This document and its contents are copyright protected.
  1383.   Redistribution of this document is permitted as long as the content
  1384.   remains completely intact and unchanged.  In other words, you may
  1385.   reformat and reprint or redistribute only.
  1386.  
  1387.  
  1388.  
  1389.  
  1390.  
  1391.  
  1392.  
  1393.  
  1394.  
  1395.  
  1396.  
  1397.  
  1398.  
  1399.  
  1400.  
  1401.  
  1402.  
  1403.  
  1404.  
  1405.  
  1406.  
  1407.  
  1408.  
  1409.  
  1410.  
  1411.  
  1412.  
  1413.  
  1414.  
  1415.  
  1416.  
  1417.  
  1418.  
  1419.  
  1420.  
  1421.  
  1422.  
  1423.  
  1424.  
  1425.  
  1426.  
  1427.  
  1428.  
  1429.  
  1430.  
  1431.  
  1432.  
  1433.  
  1434.  
  1435.  
  1436.  
  1437.  
  1438.  
  1439.  
  1440.  
  1441.  
  1442.  
  1443.  
  1444.  
  1445.  
  1446.  
  1447.  
  1448.  
  1449.  
  1450.  
  1451.  
  1452.  
  1453.