packagemonkey(1)

NAME
packagemonkey - Tool to make packaging easier

DESCRIPTION
Creating installable packages for Linux distros has always been a bit of a black art. There is a lot of documentation out there and it's often voluminous and not especially easy to interpret. When doing packaging by hand there are also many ways to go wrong. Packagemonkey is intended to make packaging simpler, and enable the creation of multiple different types of package including deb, RPM, ebuild, Arch and PET.

INSTALLATION
The easiest way to install is from a pre-compiled package, a number of which are available at:
    https://build.opensuse.org/project/show?project=home%3Amotters%3Apackagemonkey But if you prefer not to get involved with binaries then this program is pretty easy to compile and install as follows. Check out the latest source code: git clone https://github.com/fuzzgun/packagemonkey.git
Then to build and install: cd packagemonkey
make
sudo make install If you wish to generate packages for the packagemonkey application itself then run the generate.sh script. This will generate a number of scripts:
    debian.sh
    rpm.sh
    arch.sh
    puppy.sh
    ebuild.sh
    slack.sh Those scripts may then be run in order to generate packages. The debian.sh script will generate a package within the directory one level above and the others create their own subdirectories within which the built packages can be found.

EXAMPLE: PACKAGING SOME PRE-EXISTING BINARIES
As the most likely kind of scenario it is assumed that you have somehow created some binaries or some scripts which you wish to turn into an installable package. First create a directory for your package and give it the name of the project. The project name should be all lower case, and not include the version number. Create a subdirectory called "install", then insert your files within that directory using the same directory tree as you wish to be reproduced on the installed system. For example if your project was called "foobar" the directory tree might look like the following:
    foobar
    foobar/install
    foobar/install/usr
    foobar/install/usr/bin
    foobar/install/usr/bin/foobar (the binary) To create packaging files and scripts first make sure that you are in the foobar directory, then you could then run something like:
    packagemonkey --name "Foo Bar" --cmd --dir "." -l "gpl3" -e "Bob Mottram (4096 bits) <bob@robotics.uk.to>" --brief "Example package" --desc "Example of how to create a package using packagemonkey" --homepage "https://github.com/username/foobar" --section "utils" --version "0.10" --categories "Utility/ConsoleOnly" --compile "-lz" --dependsdeb "build-essential, lintian" For convenience it may be a good idea to put that into a script, so that it can easily be called again later without needing to be re-typed. If you list the contents of the current directory (ls *.sh) you should then notice that a number of scripts have been created.
    debian.sh - create a Debian package
    rpm.sh - create an RPM package
    arch.sh - create a package for Arch Linux
    puppy.sh - create a package for Puppy Linux
    ebuild.sh - create a package for Gentoo
    slack.sh - create a package for Slackware You can run any or all of these scripts to generate the relevant packages. An important point to stress here is that with the exception of puppy.sh and ebuild.sh you will need to be running on a suitable system in order to create the package successfully. So for example to create an RPM you will need to be running an RPM based distro (possibly as a virtual machine). A handy alternative is to build packages using Open Build Service, which avoids needing to use a lot of virtual machines.

PACKAGING SCRIPTS
If you are packaging scripts written for an interpreted language, such as Python or Perl, then you don't need to use the install directory as in the previous example. Put your script files into a subdirectory called src then run something like the following, substituting your own project details.
    packagemonkey -n "My Python Project" --cmd --dir "." -l "bsd" -e "Bob Mottram (4096 bits) <bob@robotics.uk.to>" --brief "Example Python Project Packaging" --desc "Example of how to use packagemonkey with a Python project" --homepage "https://myprojecturl" --repository "https://myprojectrepository.git" --section "utils" --version "0.1.2" --categories "Office/Email" --dependsdeb "python (>= 2.7.0)" --mainscript "main.py" An important option is mainscript which determines which script should be called first. So in the above example there is expected to exist a script called src/main.py

PACKAGING LIBRARIES
To package a C, C++ or Vala library put your code into a subdirectory named src and ensure that the name of the project and project directory name begins with "lib". An example is as follows:
    packagemonkey -n "libgpr" --version "1.03" --cmd --dir "." -l "bsd" -e "Bob Mottram (4096 bits) <bob@robotics.uk.to>" --brief "Library for genetic programming" --desc "Making the inclusion of Genetic Programming easy within any C/C++ application. Genetic programming (GP) is a powerful technique, inspired by the process of natural selection, which can be utilized to automatically discover programs which produce a desired input to output transformation. Both classical tree-based and Cartesian forms of Genetic Programming are supported, including self-modifying variants." --homepage "https://github.com/fuzzgun/libgpr" --repository "https://github.com/fuzzgun/libgpr.git" --section "libs" --categories "Development/ArtificialIntelligence" --cstandard "c99" --compile "-lm -lz -fopenmp" --dependsdeb "gnuplot, libz-dev" --dependsarch "gnuplot, libzip"

CHANGELOG
Once packaging files have been generated then the master changelog is the one within the debian subdirectory. Changes made to debian/changelog will update the RPM spec file automatically if you subsequently run packagemonkey again to regenerate the files.

USING PACKAGEMONKEY WITH OPEN BUILD SERVICE
Open Build Service (OBS) allows you to easily create packages for multiple distros. The only down side is that it doesn't do the hard part of creating all the necessary packaging files. However, when you combine OBS with packagemonkey this results in more of an end-to-end packaging solution. If you're creating Debian packages then upload:
    ../foobar_version.orig.tar.gz
    ../foobar_version.orig.tar.gz.asc
    ../foobar_version-1.debian.tar.gz
    ../foobar_version-1.dsc

If you are creating RPM packages then upload:
    rpmpackage/foobar.spec
    ../foobar_version.orig.tar.gz If you are creating Arch packages then upload:
    archpackage/PKGBUILD
    archpackage/foobar-version.tar.gz Why don't we upload the source file created by running the Debian script? OBS seems to expect Arch source packages to have a specific filename format, without the "orig" and with a dash instead of an underscore. Building Arch packages also typically only seems to work if you select the "Arch Extra" rather than the "Arch Core" repository.

OPTIONS

-n,--name<projectname>
    The full name or title of the project. This may contain upper case characters, and may be different from the name of the project directory.

-d,--dir<directory>
    Set the directory of the project to be packaged. If this is set to "." then the current directory will be used.

-c,--cmd
    Used to indicate this is a command line project. If this option is not used then an icon and desktop file suitable for a GUI application will be generated.

-b,--binaries<files>
    Directory containing binaries or scripts to be packaged. By default this is a subdirectory called "install".

--compile<args>
    Additional arguments to add to the compilation.

-l,--license<type>
    The license type (gpl2|gpl3|lgpl2|lgpl3|agpl|agpl3|mit|bsd|apache|mozilla)

-e,--email<address>
    Set full name and email address.

--brief<description>
    A brief one line description of the project.

--desc<description>
    A full description of the project.

--homepage<url>
    URL of the project home page.

--repository<url>
    URL of the version control repository.

--src<url>
    URL of the compressed source code.

--srcdir<directory>
    Subdirectory within which source code will be located. This is typically "src". The directory should only be one level deep.

--section<sections>
    Debian sections.

--categories<cat>
    desktop file categories.

--m,mime<types>
    Mime types which the project can handle.

--dependsdeb<packages>
    Deb packages which the project depends upon.

--builddeb<packages>
    Deb packages required to build the project.

--dependsrpm<packages>
    RPM packages which the project depends upon.

--dependsrpmdistro<packages>
    Distro-specific RPM packages which the project depends upon. The first entry should be the name of the distro. For example:
        --dependsrpm "sqlite"
        --dependsrpmdistro "mandriva, sqlite3" This will use the package "sqlite" by default, but if the operating system is Mandriva then it will use the "sqlite3" package instead.

--dependsarch<packages>
    Arch packages which the project depends upon.

--dependspuppy<packages>
    Puppy packages which the project depends upon.

--dependsebuild<packages>
    Ebuild packages which the project depends upon.

--buildrpm<packages>
    RPM packages required to build the project.

--buildrpmdistro<packages>
    Distro-specific RPM packages which the project depends upon. The first entry should be the name of the distro. For example:
        --buildrpm "sqlite-devel"
        --buildrpmdistro "mandriva, libsqlite3-devel" This will use the package "sqlite-devel" by default, but if the operating system is Mandriva then it will use the "libsqlite3-devel" package instead.

--buildarch<packages>
    Arch packages required to build the project.

--list-sections
    List the possible Debian sections.

--list-desktop
    List the possible desktop file categories.

--debian<version>
    Set the Debian version.

--mainscript<filename>
    If the project uses a scripted language, such as Python or Perl, then this specifies the initial script to be run. This should be just the filename and not include the full path.

--cstandard<standard>
    The standard to be used by the gcc or g++ compiler. Examples are c99 and gnu99.

--librarypath<paths>
    Specify LD_LIBRARY_PATH.

--suggestsdeb
    Suggested Debian packages.

--suggestsarch
    Suggested Arch packages.

-t,--tests
    Run unit tests.

-v,--version<number>
    Show or set the project version number. If only a single option exists then this will return the version number of packagemonkey, otherwise in a multi-option situation it can be used to set the version number of the prokect to be packaged.

-r,--release<number>
    Set the project release number.

-h,--help
    Show help.

SEE ALSO
lintian(1)

BUGS
Report bugs at https://github.com/fuzzgun/packagemonkey/issues

AUTHOR
Bob Mottram (4096 bits) <bob@robotics.uk.to>
https://github.com/fuzzgun/packagemonkey