Fuck you, Debian.

Dibya Chakravorty
Broken Window
Published in
4 min readNov 3, 2016

This time the culprit was Debian.

I didn’t want much from it. I had just finished writing a Python application for bookmarking music and wanted to package it for Debian based distributions. My aim was to distribute it out in the wild and get some feedback. I thought this would be easy.

Python has been around for 25 years now, Debian for 23 years. You’d think packaging a Python application for Debian would be easy, right? I don’t blame you, I thought so too! But this apparent “simple” task turned into a nightmare, and almost ended with me throwing my computer out of the window in a fit of rage and anger.

It all started with the very demanding Debian packaging tool, which is called apt-get. In order to package an application for Debian, one needs to specify the application’s dependencies in a control file. This is done in the Depends field, as shown below.

Source: someapp
Section: unknown
Priority: extra
Maintainer: Some Developer <some-developer@fuckyoudebian.org>
Build-Depends: debhelper (>=9)
Standards-Version: 3.9.4
Homepage: <insert the upstream URL, if relevant>

Package: someapp
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, python, python-numpy
Description: <insert up to 60 chars description>
<insert long description, indented with spaces>

In this example, python and python-numpy are the two dependencies. When installing the app, apt-get automatically installs the dependencies before it installs the app itself. This modular design of installing applications by specifying dependencies (instead of including them in the package) leads to smaller package sizes in Debian.

But for this to work, the dependencies must be present in the official Debian repositories or must be installable via PPA. This is strictly enforced by apt-get. If you don’t follow it and download some dependencies by bypassing apt-get during installation, then your package will be considered “insecure” and will never be included in the Debian official repositories. They take their job very seriously.

Unfortunately, the Python community does not give a fuck about this. In the world of Python, dependencies are managed by their “own” package manager, called pip . The typical way to specify dependencies in Python is via the install_requires field in the setup.py script, which looks as follows.

#!/usr/bin/env python

from distutils.core import setup

setup(name='Somepackage',
version='1.0',
description='Some package',
author='Some Developer',
author_email='some-developer@fuckyoudebian.org',
packages=['somepackage'],
install_requires = ['numpy', 'sounddevice']
)

As you can see, this app depends on numpy and sounddevice. So if you now want to package this app for Debian, then the Debian package will naturally depend on these two libraries too.

For numpy, there’s a corresponding package in the Debian repositories called python-numpy, so we can just include that in the control file. This takes care of resolving the first dependency. But here comes the catch…wait for it…there is no sounddevice package in Debian! Yes, you heard me right. It’s simply not there, so there’s no way to use it in a Debian package!

This is not just an isolated problem with sounddevice. Countless apps on PyPi (the official Python Package Index) are not on the Debian official repositories. So if you use them in your Python project, you can’t package the application for Debian anymore.

Fantastic, isn’t it?

What do the gurus in Debian say about this? Well, they have two solutions.

  • Suppose your Python package has 10 dependencies that are not in the Debian official repository. In this case, you are suggested to package these 10 Python libraries first, submit them to the Debian official repository and then package your own app. Basically, you package 11 apps instead of 1. This is Debian’s “viral packaging strategy”.
  • If you are feeling too lazy to package 11 apps, no worries. You are then suggested to refactor your code so that you only depend on the Python standard libraries and nothing else. If you try hard enough, this can be done. This is also the only true way of becoming a “Python ninja”.

So there you go. I hope you understand why I almost threw my computer out of the window while trying to package my python application for Debian.

In this world where everyone wants their own package manager, it’s a surprise that we hardly get anything done. Both Debian and Python has been here for a very long time now and you would expect that they are well integrated by this time. Yet, this is far from the actual reality.

I finally resolved this by saying “fuck you, Debian”, like many other companies like Dropbox and Spotify have said in the past. These companies offer their “insecure” apps from PPAs to users who are willing to take the risk (and guess what users think about this? They don’t care either way, as long as it comes from reputed companies).

I made my precious .deb installer by using dh_virtualenv This is an open source tool published by Spotify that makes it easy to include pip dependencies in a .deb installer. It solves the problem of integration. Of course, by doing so, it breaks Debian policies. As a result, my package will never see the light of the Debian official repositories.

--

--