An example on using packer

This page shows a sample session with packer, in which I packed packer itself. Everything done on this page was done using packer 0.1.0. Things may change slightly in future versions. Line breaks have been inserted into the output so it will fit on the screen.

I first opened a console and changed into the packer directory. I then ran the "packer" program with no arguments to launch the wizard:

$ packer Welcome to packer. Packer needs to know some information before it can generate packages. At any time, you can leave packer by pressing Ctrl+C and packer will resume from the last step completed. Press enter to continue...

I pressed enter and then completed step 1. Everything in this step is fairly trivial.

Step 1 of 11: Package name, version, revision Enter package name: packer Enter display name (What the package is called; may be the same as the package name) : packer Enter package version: 0.1.0 Enter package revision [1]: 1

Step 2 also was easy. The only problem was that packer asked for the location of the tarball on the web and I did not have the tarball online yet. I thus put bogus information into that field with the intent to relaunch packer at a later time and add the information.

Step 2 of 11: Program information Enter package homepage: http://packer.sourceforge.net Enter package tarball location. You really should use [[version]] ins tead of the version number here, if possible. Be sure to include the protocol (which should be either http:// or ftp:// for this) at the b eginning: TODO Enter copyright statement (ex. (c) Copyright 2004-2005 John Smith): (c ) Copyright 2005 Daniel Milstein Enter your name , followed by your email in triangular brackets (ex. John Smith<john@smith.name>: Daniel J. Milstein <djmilstein@gmail.com> Enter the name of the maintainer and his/her email in the same format as before: Daniel J. Milstein <djmilstein@gmail.com> What license does this program use (abbreviate if applicable). It is _strongly_ recommended that you enter the name of the license as it a ppears on the list at http://packer.sf.net/lic. For proprietary licen ses not listed, please use one of the general terms "Proprietary", "F reeware", "Shareware", or "Charityware".: Apache-2.0

Packer then asked for files to put in /usr/share/doc:

Step 3 of 11: Doc and Config files About to edit the docs file. Please list one documentation file per li ne. These files will be installed for you in /usr/share/doc in EVERY s ubpackage, so it may not be appropriate to put all documentation here. Press enter to continue...

After pressing enter, packer launched my default text editor (which I will decline to mention so I am not flamed for using a different one ;-) ). It automatically detected the NOTICE file and put it in. I added the rest of the documentation and pressed enter:

NOTICE doc/depends

I then saved the file and exited the editor. Packer then displayed:

About to edit the list of configuration files. Same format as above, b ut these must be manually installed.

As packer has no configuration files, I saved the blank file without modification. Packer then asked me about build dependencies. Since there is nothing the build in packer (it is written in Perl, an interpreted language), I answered no:

Step 4 of 11: Build deps Does your package need anything to build besides the standard build tools (gcc, g++, make, etc)? n

Packer then asked how to build the package. Had packer detected a configure script, it would have offered to do this step, as well as the following two steps that deal with installing and cleaning the package, automatically.

Step 5 of 11: Build commands About to edit file. Please put in it the commands, enter separated, to build your package. Only build it, do not install it. Many packages will only need to put "make" for this. Do NOT put in a shabang (#!) at the beginning of the file. Press enter to continue...

As previously noted, nothing in the package needs to be compiled, so I left this step blank

Step 6 of 11: Clean commands About to edit file. Please enter the commands necessary to delete fil es created during the build stage. Many packages will only need to pu t "make clean". Press enter to continue...

I left this part blank as well.

Step 7 of 11: Install commands About to edit file. Please enter the commands necessary to install the package to $install_dir (which will be defined before the install code runs) as the root directory. If your package cannot do it, you ma y want to exit packer now, patch the package, and re-enter packer. Press enter to continue...

The software contains a Makefile to install itself, so I put the following in the file:

make install DESTDIR=$install_dir

The DESTDIR= defines the DESTDIR variable within the Makefile. The Makefile installs to locations such as ${DESTDIR}/usr/bin. Thus, if DESTDIR is not defined (as in when the Makefile is invoked on the command line as "make install", the Makefile will simply install to /usr/bin.

Step 8 of 11: Packages Do you want to split this package into two or more packages?:n

To "split" a package is to make software contained in a single directory into multiple packages. This might be useful if multiple pieces of independent software is located in a directory. It is also a very good idea to split the package if a sizable part of the software is platform independent (ex. data files such as graphics and sound). This way, less space will be taken up by packages if the package is built for multiple architectures, as only the package dependent part will need to be rebuilt. If you plan on submitting your package to Debian, which automatically builds packages for multiple archetectures, this can be a large concern. Note that package splitting is ignored when building autopackages and gentoo ebuilds, as splitting packages does not make sense with these package types. I decided not to split the package because it contains no large data files (and also, it is entirely platform independent).

Is this package platform independent?y Launching text editor to edit the package summary (a short phrase wel l under 80 characters). Press enter to continue...

I entered the following for the summary:

A user-friendly package creation tool

Launching text editor to edit the package description. Each line shoul d be under 80 characters. Press enter to continue...

I entered the following:

Packer is a tool that helps in the creation of packages. Packer works by asking the user for information about a program, and then by generating files needed to create Debian, RPM, Slackware, and Autopackage (distribution independent installers) packages based off of that information. Unlike similar tools, packer generates files that are of comparable quality to those that are hand-crafted.

Launching text editor to edit the package dependencies. Dependencies are the most non-trivial part of packer. The format for dependencies is one file that your package depends on per line. This can optionally be followed by 1 or more spaces a qualifier (>=, <, =, etc), and a version number. Packer will automatically convert the file to the name of the package that contains that file. You only need to include 1 file per package that your package will depend on. In addition, you do not need to list files that will be present if the other files are present. For example, if your package needed the lua and lualib include files, it would be enough to put "/usr/include/lua50/lualib.h >= 5.0", since the lua include file will be present if the lualib include file is present because in all packaging systems with dependencies, lualib depends on lua. Dependencies can also be manually specified. See the "depends" files in /usr/share/doc/packer for more information on this. Press enter to continue...

I entered the following:

/usr/bin/perl >= 5.8 /usr/bin/wget /usr/bin/convert /usr/bin/bzip2 /usr/bin/fakeroot-tcp /usr/bin/less /bin/gzip dr:cdbs dr:debhelper >= 4.1.0 ds:rpm >= 4.1

The package depends on perl 5.8 or greater. Per the format, I thus put an example file that can be found in any distribution's perl package, and then a version qualifier. The next version did not matter for the next 6 dependencies, so I did not specify one. "dr:" and "ds:" are special, rarely needed, prefixes that are documented in /usr/share/doc/packer/depends. They are ignored when not building a debian package. The text after "dr:" is included in the Debian "Recommends:" section, while the text after "ds:" is included in the Debian "Suggests:" section.

Launching text editor to edit post-installation actions for this package. In almost all cases, you will want to leave this blank Press enter to continue...

This package does not require any post-installation actions, so I left the file blank.

The category list is about to be fed through less. Examine the list and find the number of the category that the software fits best in. Packer will then automatically categorize your software in all software packaging environments that it supports based on your selection upon package generation. Press enter to continue...

Packer then presents a very large list of potential package categories through the less pager. The program I am packaging falls under the category "Development/Tools/Other", which happens to be number 55. I then quit less using q.

Please type the number corresponding to the category that you want: 55 Packer recommends the following categorizations: 1. Debian: devel 2. SuSE: Development/Tools/Other 3. Mandriva: Development/Other 4. Redhat/Fedora: Development/Tools 5. Gentoo: dev-util 6. Freedesktop.org menu entry: Development; 7. Debian menu entry: Apps/Programming 8. Mandriva menu entry: More Applications/Development/Tools Enter the number corresponding the the category you want to modify, or press enter to accept the current categorizations. If your program is an educational program, your menu entries will almost certainly need to be manually recategorized.

I am satisfied with the automated categorization, so I just press enter.

Would you like to edit menu items for this package?

It would be inappropriate for the program I am packaging to have a menu entry, so I will just press "n" and then enter. If I needed a menu entry, packer could have created Debian menu files, and Mandriva menu files, and freedesktop.org .desktops (which most other distributions use for menu entries) as well as automatically handling the installation of either .png or .xpm icons depending on the distribution.

Step 10 of 11: Changelog About to launch editor. Please enter a changelog entry for version 0.1.0-1. Just put down one change that you made per line. Do not prefix anything with a * or anything like it - packer will add that for you. Press enter to continue...

I enter the following into my editor:

Initial packaging using packer

Step 11 of 11: Patching If you have patches for this packages, simply put them in the packer/patches directory. All patches must end of .diff and must not be compressed. They also must be appliable with -p1. To generate a patch from the original tarball to the current working directory, ignoring packer-generated files, you may use the differ tool, which is distributed with packer. It can be called with "differ tarball", where tarball is a tar.gz file with the package sourcecode (if the source code came in a .tar.bz2 file, you will need to repackage it to use it as .tar.gz file to use it with differ). Note that the patch that differ generates (or any patch with the name "differ.diff") will only be applied to RPM and Gentoo packages. It should be noted that generated desktop files reside in the packer directory. Thus, if you utilized this feature, you must have either have the packer directory in the original tarball or include a patch to add the packer directory. Otherwise, building RPMs will fail. Press enter to continue...

This is just an informational message about patches. I do not need to apply any patches, so I will ignore it.

Finally, packer displays a little goodbye message:

Packages can now be created. Use packer --help to see how. Once your packer files are included in the package, please add packer to the packer registry at http://packer.sf.net/reg.html. Thank you for using packer!

I then wanted to edit the packer configuration to add in the tarball location that I never specified:

$ packer What would you like to change? 1: Package name, version, revision 2: Program information 3: Doc and Config files 4: Build deps 5: Build commands 6: Clean commands 7: Install commands 8: Packages 9: Package splitting 10: Changelog 11: Patching Type q to quit 2 Enter package homepage [http://packer.sourceforge.net]:

If I already entered something it is in square brackets. Since I do not want to change it, I can simply press enter and packer will leave it as is. I then complete the section as normal but with the new tarball location. Packer will then take me back to the menu, where I can press "Q" to quit. Now to actually generate the packages. This is done by running packer with options. You can find all of the options using packer -h. I used packer -efb, which generates and builds all of the type of packages that packer supports, overwriting directories such as "rpm", "autopackage", "debian", "gentoo", and "slack" in the process. When the process finished, RPM dumped its 3 packages (one for a Fedora/Redhat RPM, one for a Mandriva RPM, and 1 for SuSE RPM) into the RPMS subdirectory of the RPM root directory. Unless you overrode it in your .rpmmacros file, the root directory is probably in either /usr/src/rpm or /usr/src/redhat/rpm. Debian and slackware packages will be put in the parent directory. Autopackages will be put in the current directory. Files that are generated to build the packages and Gentoo ebuildsare in directories named after the packaging system (for example, RPM spec files are put in the "rpm" directory).

If your package uses the unmodified output of packer for packaging, listing your package in the packer registry can help Linux distributors find it.

Hosted by: SourceForge.net Logo

Copyright (c) 2005-2006 Daniel Milstein