Why Debian Package but Not Python Egg or Wheel?
There are several reasons. Including:
- The application may consist of the other components on top of the other languages
- The application may need more system-wide operation or supported by the other components of the system.
Theoretically, Python egg or wheel package could meet the same needs above, e.g. via python os module operation. However there have been many powerful and mature tools existing for years e.g. dpkg, dh_make and pybuild. We don't re-invent "wheels".
Debian Package Is the Foundation of Ubuntu Classic
Ubuntu are now shipping with mainly two package formats: the conventional Debian packages, and the innovative Snap packages. Both of the packages are now running and supported in the meantime in your current Ubuntu Desktop and/or Server if you are not using "Ubuntu Core" image. The Ubuntu image consists of mainly Debian packages is called "Ubuntu Classic" and we will just call it "Ubuntu" for short. The Ubuntu image consists of Snap packages is so-called "Ubuntu Core", and "UC" for short.
We will focus on the Debian part in this article.
A Lot of Debian Packages in Ubuntu Are Python Packages
There are plenty of Python applications in Ubuntu are shipped as a Debian package. For example, the fantastic beautiful desktop installer "Ubiquity", and many default applets on the top corners of your Ubuntu default desktop. It's important to know and follow the rule to pack a Python application in Debian package format.
Packing a Debian Python Package
The Core Concept When Packing a Debian Package
The rules of packing a Debian package is tremendously complicated, and it will take years and years to make us a skilled Debian package maintainer. Please do not feel frustrated when packing your first few Debian packages because it is definitely normal that we don't make a Debian package smoothly at the beginning.
By focusing on the core files may help you get things done quicker and easier (and feel more accomplished!!)
- debian/control
- debian/rules
debian/control tells the package manager how this package will work together with the other Debian packages. It works from and for dependency point of view.
debian/rules tells the package manager what this package will actually do when installing and removing it from the whole system. It works from and for implementation and deployment point of view.
Approaches and Tools
There are at least 3 types of approaches, and the corresponding tools are:
- Manually create/edit files without any helper scripts (shipped by devscripts package in Ubuntu) by following the rules of Debian package format.
- Manipulate devscripts like dh_make based on core tools like dpkg and dpkg families.
- debmake which integrates pybuild and devscripts
The above approaches could work together by mixing any of them. The only rule to follow is making sure the final files under the debian folder, especially control and rules, follow the Debian package policy and rules.
I usually combine debmake, debuild and some manual Python specific configuration editing to build my own Debian Python package Regarding Python specific configuration, please see below.
Python specific configuration
Debian Python Policy shows the details of this topic. For example, what your dependency should look like actually if you are packing a pure Python2 (not suggested), pure Python3, or Python2/Python3 application.