Ignore:
Timestamp:
Nov 9, 2009, 3:35:35 AM (14 years ago)
Author:
mitchb
Message:
Complete overhaul of package building/patching documentation
File:
1 edited

Legend:

Unmodified
Added
Removed
  • trunk/server/doc/package-build-howto

    r1349 r1353  
    11This document is a how-to for building new packaages for scripts.mit.edu.
    22
    3 * Ensure you have a scripts-build user account, as documented in install-howto.
     3Prerequisites
     4=============
    45
    5 * su scripts-build -
     6  * A trusted scripts.mit.edu server
     7  * A scripts-build account on that server (but that was created when it
     8    was installed, or something's wrong)
     9  * A set of personal credentials for the scripts svn repo
    610
    7 * Use the Makefile to build the scripts.mit.edu-specific Fedora
    8   packages.
    9   - export PATH=$PATH:/usr/sbin
    10   - make download
    11   - make setup
    12   - make all
    13   - openafs-devel is a build-dependency of accountadm, so you'll need to
    14     install the openafs-devel package you just built by hand when that fails.
     11Directions
     12==========
    1513
    16 * Add the packages to the repository by using a trusted machine to
    17   - krootscp root@build-server.mit.edu:/home/scripts-build/rpmbuild/RPMS/x86-64/* /mit/scripts/rpm-fc11/
    18   - cd /mit/scripts/rpm-fc11 && createrepo .
    19   - If you don't have a trusted Fedora machine, you can use createrepo
    20     -o ~/foo . and then manually install the generated file
     14  * Log into the server as root
    2115
    22 * Rebuild mit-zephyr on a 32-bit machine, like the one at Joe's home.
     16  * /bin/su scripts-build # It's a bad idea to build as root.  This is
     17                          # less urgent than it used to be, because you'll
     18                          # be building using mock in a chroot, but it's
     19                          # still good habit.  Also, if you work in
     20                          # /srv/repository as root, scripts-build won't
     21                          # be able to change some of the resulting files
     22
     23  * cd /srv/repository
     24
     25  * svn up  # Important both to build with current code, and because the
     26            # svn revision becomes part of the package release number,
     27            # and you can infer whether changes in the code were made
     28            # before or after a particular build by looking at the package
     29            # and svn release/revision.
     30
     31  * cd server/fedora
     32
     33  * # Look in the .dload directory.  If you want to build with a newer
     34    # version of any upstream packages that are there, then
     35    * rm .dload/[OLD-PACKAGES].src.rpm # It's fine to delete all SRPMs here
     36    * rm download_stamp
     37
     38  * make [PACKAGE-YOU-WANT] # e.g. 'make httpd' builds Apache with our patches
     39    # Note that openafs-devel is a build-dependency of accountadm, so if
     40    # this is a new Fedora release being bootstrapped, you'll have to
     41    # build openafs and install its -devel package before building accountadm
     42
     43  * # If the build succeeds, the mock logs, build log, binary and SRPMs
     44    # will be in /var/lib/mock/fedora-[RELEASE]-{x86_64|i386}/result (note that
     45    # this will be cleared out each time you start a new build, so if
     46    # you're building several packages in succession, copy the results
     47    # somewhere safe after each build to preserve them)
     48    # Add the packages to the repository by using a trusted machine and
     49    krootscp root@[BUILD-SERVER]:/var/lib/mock/fedora-[RELEASE]-{x86_64|i386}/result /mit/scripts/rpm-fc[RELEASE]
     50
     51  * # Rebuild the repo metadata to include the new packages.
     52    cd /mit/scripts/rpm-fc[RELEASE]
     53    # If you have a trusted machine:
     54    createrepo .
     55    # Otherwise, on a scripts server, as root:
     56    mkdir /root/repodata-YYYYMMDD # Or any suitable temp directory
     57    createrepo -o /root/repodata-YYYYMMDD .
     58    # Then from your trusted machine
     59    krootscp -r root@[BUILD-SERVER]:/root/repodata-YYYYMMDD /mit/scripts/rpm-fc[RELEASE]
     60    # Sanity check the files, and then replace the current repodata directory
     61    # with the one in repodata-YYYYMMDD.
     62
     63Patching packages
     64=================
     65
     66  * To make changes to the packages that we are the upstream maintainers
     67    of (that is, the packages that the Scripts Team wrote):
     68    * The authoritative source lives in server/common/oursrc/[PACKAGE]
     69    * The RPM spec file is server/fedora/specs/[PACAKGE].spec
     70    * You directly make the relevant changes to those files, commit to
     71      svn, and then rebuild the package as above to include the new changes.
     72
     73  * To make changes to the upstream packages that we "scriptsify":
     74
     75    * The authoritative upstream source comes from the SRPM in the upstream
     76      yum repo, or in odd cases like openafs, from some other URL.  When
     77      you 'make [PACKAGE]' in SVN/server/fedora, if download_stamp has
     78      been removed, the SRPMs are all refetched into
     79      SVN/server/fedora/.dload, and then installed with 'rpm -i'.  This
     80      results in the source patches, and tarballs landing in ~/rpmbuild/SOURCES
     81      and the spec files landing in ~/rpmbuild/SPECS.  You can also
     82      manually get individual SRPMs for a package by doing this (these
     83      steps work fine as a mortal user, including the 'rpm -i'):
     84      * yumdownloader --source [PACKAGE]
     85        # That deposits [PACKAGE]-[VER]-[RELEASE].src.rpm in the current dir
     86      * rpm -i [PACAKGE]-[VER]-[RELEASE].src.rpm
     87        # That unpacks the SRPM, placing the source tarball and patches in
     88        # ~/rpmbuild/SOURCES and the spec file in ~/rpmbuild/SPECS; it
     89        # does *not* globally install anything, and doesn't require root
     90      If you prefer to not install the file, you can simply extract it
     91      into a directory by running:
     92      * /mit/ghudson/scripts/rpmx [PACKAGE]-[VER]-[RELEASE].src.rpm
     93
     94    * If you develop a patch to the upstream source, you should save a
     95      diff with your changes and add it to the repo as
     96      SVN/server/common/patches/[PACKAGE]-[SHORT_DESCRIPTIVE_STRING].patch
     97
     98    * To cause your patch to be applied when the package is built, you
     99      will need to save a copy of the original spec file for the upstream
     100      package, then modify it to add a line like:
     101        Patch[NUM]: [PACKAGE]-[SHORT_DESCRIPTOVE_STRING].patch
     102        # This should generally go after the last existing Patch line
     103        # in the file, and [NUM] should be significantly larger than
     104        # the upstream Fedora patches, to avoid conflicts later.  This
     105        # line tells rpmbuild where the contents of the patch live.
     106      You also add a line like:
     107        %patch[NUM] -p1 -b .[SHORT_DESCRIPTIVE_STRING]
     108        # This should generally go after the last existing %patch line
     109        # in the file, [NUM] should be the same as in the Patch line, and
     110        # tells rpmbuild that this is the point at which to actually apply
     111        # the patch
     112
     113    * The Release tag in the spec file should have ".scripts.%{scriptsversion}
     114      inserted into it just before %{?dist}, or at the end of the release
     115      if %{?dist} is unused.
     116      # e.g.          Release: 1%{?dist}
     117      # changes to    Release: 1.scripts.%{scriptsversion}%{?dist}
     118      This causes the package version to include the string "scripts"
     119      and our SVN revision number (which is set by the Makefile) for
     120      easy identification (this version will also be greater than the
     121      upstream version, so the system will prefer to update to it).
     122
     123    * If the scriptsified version of the package needs to be installed
     124      on the servers, and a new upstream version would break scripts
     125      without our changes, add a line like this:
     126        Provides: scripts-[PACKAGE]
     127      and correspondingly, add "scripts-[PACKAGE]" to the Requires line
     128      in SVN/server/fedora/specs/scripts-base.spec (and remember to
     129      build, upload, and deploy a new scripts-base package)
     130
     131    * Though we're not always good about it, do feel encouraged to add
     132      an entry at the top of the %changelog section near the bottom of
     133      the spec file explaining your modifications
     134
     135    * When you're finished with the updates to the upstream spec file,
     136      create a diff from the upstream spec file to your new version,
     137      and add it to the SVN repo as
     138        SVN/server/fedora/specs/[PACKAGE].spec.patch
     139
     140    * If we haven't previously scriptsified this package, you'll need
     141      to add it to the upstream_yum line in SVN/server/fedora/Makefile,
     142      and remove the download_stamp file so that it gets fetched next
     143      time you run 'make [PACKAGE]'.
     144
Note: See TracChangeset for help on using the changeset viewer.