Skip to main content

debpacker

debpacker is a Debian package creation tool. It builds DEB files from source code based off a configuration file and build script.

Important features

  • Easy integration into even enterprise-level build tools
  • Super-simple JSON configuration file that can be easily generated

Requirements

  • dpkg, but, c'mon, you should already have that
  • python3
  • pigz
  • pytz (a pip package)
  • tzlocal (a pip package)
  • zmtools (a pip package)
  • gh (the GitHub CLI)

Structure

When working on an application, a folder should be placed in the root of the source code called .debpack. The structure of this folder is as shown.

source_code_folder/
└── .debpack/
    ├── config.json
    ├── build
    └── maintainer_scripts/
        ├──preinst
        ├──new-preinst
        ├──old-preinst
        ├──postinst
        ├──old-postinst
        ├──conflictor's-postinst
        ├──deconfigured's-postinst
        ├──prerm
        ├──old-prerm
        ├──new-prerm
        ├──postrm
        ├──old-postrm
        ├──disappearer's-postrm
        └──new-postrm

The config.json file is the file that determines what metadata the Debian package will be tagged with and where source/compiled files should be placed.

The build script is the script that is run in order to compile or otherwise build the source code files in a certain manner. You should use it to do something with the source code files and place them into the target folder. This is provided for convenience as the evironment variable SRC. Why do I use this? Because I never learned make! Yay, reinventing the wheel!

The maintainer-scripts are the apt control scripts that run under certain conditions. See here for more info. They will not be discussed in this documentaion, as this is not something specific to debpacker itself.

Packing

Switch to the root directory of the source code and run debpack [app version]. It's as simple as that. Run debpack --help for more options.

Creating your first DEB file with debpacker

Creating a DEB package with this tool is as simple as creating a configuration file with where the files are to be installed, creating a build script, and running a command when read to pack.

Here are two examples, one that requires compilation of code (C++) and one that does not (Python).

C++ example

Here's how the project's code is structured.

helloworld-in-c++/
├── helloworld.cpp
└── .debpack/
    ├── config.json
    └── build

The config.json file is as follows.

{
    "section" : "utils",
    "priority" : "optional",
    "maintainer" : {
        "name" : "Zeke Marffy",
        "email" : "zmarffy@yahoo.com"
    },
    "depends" : [
    ],
    "description" : "hello world in C++",
    "build" : {
        "files" : {
            "helloworld-c++" : "/usr/bin/helloworld-c++"
        }
    }
}

This file will specify to debpacker that this program is optional, the maintainer is Zeke Marffy, it does not require anything special to run, and when installed, the file helloworld-c++ file will be placed in /usr/bin/. But wait, where does that file come from? It's not in the file structure of the project, right?

Let's talk about the build script.

The build script is as follows.

g++ helloworld.cpp -o helloworld-c++

This script will compile the code into a binary called helloworld-c++. Thus, debpacker will use that file.

There are no maintainer scripts needed for this program. Nothing is needed to be run before or after it is installed.

So then let's pack it!

Run debpack 1.0 in the helloworld-in-c++/ folder.

And now we have a hello world C++ program packaged up in a DEB file. It is only usabale on a machine of the same architecture of the machine that compiled it, remember!

Python example

Here's how the project's code is structured.

helloworld-in-python/
├── helloworld.py
└── .debpack/
    └── config.json

Don't forget to make sure helloworld.py is executable.

The config.json file is as follows.

{
    "section" : "utils",
    "priority" : "optional",
    "maintainer" : {
        "name" : "Zeke Marffy",
        "email" : "zmarffy@yahoo.com"
    },
    "depends" : [
        "python3",
    ],
    "description" : "hello world in Python",
    "build" : {
        "files" : {
            "helloworld.py" : "/usr/bin/helloworld-python"
        }
    },
    "architecture_all" : true
}

This file will specify to debpacker that this program is optional, the maintainer is Zeke Marffy, it requires Python 3 to run, and when installed, the helloworld.py script will be placed in /usr/bin/, renamed without ".py" at the end of it, for easy running. This JSON file also specifies that this package is usable on any architecture (architecture_all), due to the fact that Python is an interpreted language.

What about the build script? There is none? Correct! In the case of this "hello world" script, as touched on in the config.json explanation, there is no build script to execute, as Python is an interpreted language. This is totally OK; a build script is optional. debpack can just copy files directly into a DEB if you would like with no compilation or otherwise build steps.

There are no maintainer scripts needed for this program. Nothing is needed to be run before or after it is installed.

Let's pack this one next!

Run debpack 1.0 in the helloworld-in-python/ folder.

And now you have a hello world Python program packaged up in a DEB file.

Extra features

  • Generate a changelog for the DEB file with the -c option
  • Automatically post resulting DEBs to GitHub's releases page with the --github_release option

Notes

Some thoughts to consider when it comes to packing an entirely Python program.

  • Should you really be using debpacker to do that, or could you do it with a pip package?
  • Is it a good idea to list Python dependencies as apt dependencies? A lot of system-package-manager-managed Python packages are not up to date, and certainly tons and tons are not even available via any known repos. Maybe you should put the installation of these in a maintainer script.
  • How are you going to perform imports of Python files that are off in different locations? I do have an answer to this one, actually. You can use zmtools's get_module function, which will allow you to specify where the Python module you want to import is.

Please, if you are unsure of how to use this tool, open an issue or (even better) email me. I am happy to assist you in fitting it into your project. So long as I don't get a lot of people asking me. :P

Metadata

Release files for debpacker 2.1.4

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for debpacker 2.1.4
File Size Uploaded Provenance
debpacker-2.1.4.tar.gz 11.6 kB Without provenance Details

Built distribution (wheel)

Table of built distributions (wheels) for debpacker 2.1.4
File Interpreter ABI Platform
debpacker-2.1.4-py3-none-any.whl Python 3 none any Details

Total release size: 21.7 kB

Release files / debpacker-2.1.4.tar.gz

Download URL debpacker-2.1.4.tar.gz
Size 11.6 kB
Tags Source
SHA-256 checksum
How to use checksums
cbf2e9b8289aee88410c439c9b2ebe3f31a8062bf13f3a35d68da832fce99b9c
BLAKE2b-256 checksum
How to use checksums
42fc53a9704941ca66c8ed1f3aa680091b7715bc2fe8fcebb2c9a35f7efe9e94
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/3.2.0 pkginfo/1.5.0.1 requests/2.22.0 setuptools/45.2.0 requests-toolbelt/0.9.1 tqdm/4.50.0 CPython/3.8.5

Release files / debpacker-2.1.4-py3-none-any.whl

Download URL debpacker-2.1.4-py3-none-any.whl
Size 10.2 kB
Tags Python 3
SHA-256 checksum
How to use checksums
18c1515ab9f5c28d6cd6ee9ce3d4ea13faa55eb837dec58047879cdd05e73d61
BLAKE2b-256 checksum
How to use checksums
4595fb899a2cb17739259ee37f47eb63a3251c7a3191213f8d3fd57a6a8f3635
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/3.2.0 pkginfo/1.5.0.1 requests/2.22.0 setuptools/45.2.0 requests-toolbelt/0.9.1 tqdm/4.50.0 CPython/3.8.5

Security for debpacker 2.1.4

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

No provenance found

None of the files in this release were uploaded with provenance metadata.

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

Release history Release notifications | RSS feed

This release

2.1.4 This release

2 release files No provenance

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page