Release Instructions

This page documents varios aspects of creating releases and binary builds suitable for distribution of the project products:

Releasing Source Code

MakeRelease

The current release procedures are reliant on the MakeRelease system, which is designed to automate (and document) as much of the process as possible.

MakeRelease can be installed as follows:

 git clone http://github.com/hardaker/makerelease
 cd makerelease
 perl Makefile.PL
 make
 sudo make install

Preliminary tasks

Before you start, check that the installed versions of autoconf, automake and libtool match the requirements for this branch (as listed under Build_System#Tool_Versions)

If the release is being built from a fresh source checkout, then you should run configure by hand before running makerelease. This is because the release process relies on running various make commands before invoking configure itself, and expects there to be a suitable Makefile already present.

Building a Source Release

In order to start packaging up a new release, change directory to the root of the code tree to be released (which should be under revision control), and run the command:

 makerelease -c dist/makerelease.xml

Most of the process is automated, and will be performed automatically, with the script simply stopping at regular intervals to allow you to verify what is being done.

There are two main steps where manual intervention is required:

• Step 4.4 - trim the file ChangeLog.reallyadd to contain just those changes applied since the last run of makerelease, and then to include these changes into the main ChangeLog file.

• Step 4.8 - merge the contents of CHANGES.new2 into CHANGES (and similarly for NEWS)

Note that it's worth spending some time on this step. Although most of the significant changes will hopefully have been tagged when they were commited, and should be extracted automatically, the descriptions are sometimes truncated or unclear. The release manager is also usually in a good position to judge the relative importance of various changes, so should move descriptions between the CHANGES and NEWS files

Notes

If a release is built from a 'clean' source tree, where configure has never been run (or not run since a "make distclean"), then Step 2.3 ("make docs" and "make mancp"), and Step 3.1 ("make distclean") will fail. These failures are not significant, and the process can be allowed to continue.

If a second release is made from the same source tree, make sure that you remove the previous 'net-snmp-{version}' directory first. Otherwise this will confuse Step 4.2 ("make depend")

There are a few other steps where manual intervention is sometimes needed (or may appear to be!)

• Step 1.2 - specify the version number for this release
• Step 2.1.1 - the library version numbers will normally only need to be tweaked for the first (.pre1) version of a given release cycle
• Step 2.3 - extracting the in-line documentation will typically generate a large number of warnings. These can safely be ignored
• Step 2.5 - there may also be a number of "new" function man pages, which are not under revision control These can also be ignored - there is no need to run git add on them.
  (In fact, the automatic generation of these man pages should probably be disabled altogether)
• Step 3.4 - the make checks test invariably fails
  The complaint about non-portable constructs in the top-level Makefile.in file can be ignored - other errors should be taken on their merits
  It will usually be necessary to explicitly continue at this point
• Step 4.1 - the make depend step will generate a large number of warnings - these can safely be ignored

• Steps 5.8 and 5.10 - If you don't have the Net-SNMP Administration secret key (or can't remember the password!), you'll have to skip these signing steps. MD5 checksums (or full package signatures) can be generated and uploaded at a later date

Publishing and Advertising

From Step 6 onwards, the process relies more on manual intervention, with relatively little being automated. The makerelease script will guide you through what is required, but won't actually perform most of these actions.

• Step 6.1 - note that the example command uses Wes' SourceForge account details. Amend hardaker to be your SF login name.

• Step 6.2 - updating the Download web page needs to be done via the git repository

• Steps 6.3, 8.1, 8.4 - these attempt to open the relevant web pages for editing, but this may well fail - update the relevant pages manually (or ignore them), and continue

Producing Binaries

Linux RPMs

There are two elements to generating a set of RPM binaries - deciding on the structure of the RPMs to create (which is controlled by the contents of the net-snmp.spec file), and actually generating these RPMs.

Traditional Net-SNMP RPM structure

Historically, the Net-SNMP project has tended to distribute just three binary RPMs:

• net-snmp (the main RPM, containing both client-utilities and the agent, together with the supporting framework)
• net-snmp-devel (header files and archive libraries, needed for developing new SNMP applications)
• net-snmp-perlmods (the perl modules)

This structure uses the RPM spec file that is included as part of the source code tree, in dist/net-snmp.spec.

The spec file also attempts to include suitable "provide" definitions which should allow these RPMs to replace the vendor-supplied Net-SNMP RPMs which come with SuSE-based and RedHat-based systems (including RHEL, Fedora and CentOS distributions).

RedHat/Fedora RPM structure

RedHat-based distributions tend to use a larger number of individual RPMs, allowing system administrators to select which elements to install (e.g. SNMP clients without the SNMP agent, or vice versa).

• net-snmp (the SNMP agent)
• net-snmp-utils (the command-line client applications)
• net-snmp-libs (shared libraries and other supporting framework)
• net-snmp-devel (header files and libraries, needed for developing new SNMP applications)
• net-snmp-perl (the perl modules)
• net-snmp-python (the python modules)
• net-snmp-gui (tkmib)

This uses the RPM spec file from the Fedora repository, which can be retrieved (together with accompanying files) using the command
git clone git://pkgs.fedoraproject.org/net-snmp

Note that this spec file includes RedHat-supplied patches to the code, which may not necessarily be relevant to the version you are working with. You may need to comment out some of the PatchN definitions, and the corresponding %patchN setup directives. It may also be necessary to amend the configure options used, and other aspects of the spec file, depending on the versions involved.

Building RPMs using rpmbuild

The traditional approach for generating RPMs uses the command rpmbuild (part of the RPM rpm-build)

The procedure is as follows:

• Create $HOME/rpmbuild/SPECS and copy the spec file there
• Create $HOME/rpmbuild/SOURCES and copy the tarball there
• If there are any patch files mentioned in the spec file, copy these to $HOME/rpmbuild/SOURCES as well
• Ensure Version in the spec file matches the version of the tarball
• Append a suitable vendor identifier to the Release in the spec file
• Run the command rpmbuild -ba $HOME/rpmbuild/SPECS/net-snmp.spec

This produces the appropriate binary RPM files (under $HOME/rpmbuild/RPMs) together with a source RPM file (under $HOME/rpmbuild/SRPMs)

Building Fedora RPMs

Fedora-based distributions can also use the command fedpkg (part of the RPM fedpkg)

• copy the spec file, source tarball and any patch files into a suitable working directory
• Ensure Version in the file net-snmp/net-snmp.spec matches the version of the tarball
• Run the command fedpkg local

(This procedure may also require the RPM chrpath to be installed)

Solaris

• SYSV packages
  • see dist/net-snmp-solaris-build
• tar balls
  • to be unpacked beneath /usr/local