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 thatpython3pigzpytz(apippackage)tzlocal(apippackage)zmtools(apippackage)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
-coption - Automatically post resulting DEBs to GitHub's releases page with the
--github_releaseoption
Notes
Some thoughts to consider when it comes to packing an entirely Python program.
- Should you really be using
debpackerto do that, or could you do it with apippackage? - Is it a good idea to list Python dependencies as
aptdependencies? 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'sget_modulefunction, 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)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| debpacker-2.1.4.tar.gz | 11.6 kB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| 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.