One of my resolutions for 2014 is to keep trying harder to talk about my Debian contributions. So here it is, on a monthly basis this time I hope, quite short this month because I’m leaving for holidays at the end of the week and I think I won’t have time to contribute more this month.
Below are some packages I updated recently:
1. Brebis, the fully automated backup checker
2. Pycallgraph, a Python library that creates call graphs for Python programs
Pycallgraph is one of the first Debian packages I have been maintaining. So when I noticed it was upgraded after so much time I was really eager to package the new version 1.0.1. Now available in Debian Sid! Just belown an example of the generated graph for the application Belier, a sysadmin tool.
3. Belier, the SSH connection generation tool
Nothing really new for Belier, the SSH connection generation tool but I updated the package in order to update the configuration of the Debian package and get rid of some warning messages. Kind of maintenance job I kept avoiding and avoiding, until now.
I’d like to take a few seconds to talk about an interesting bug report about the need for a nagios3-dev package I created asking for a new nagios3-dev or nagios3-headers package to offer a simple access to the headers of Nagios for the developers of Nagios external modules.
In Nagios, some headers are generated after the ./configure, meaning it may be platform dependent. I (and not only me, the same request was active already by someone other Nagios module developers) thought it was simple to ask the Nagios3 Debian package maintainer to offer these files in a dedicated package.
It seems until now people just add the missing files in tarball of their app or in their Debian packages, even if these Nagios headers are not really part of this application. In my opinion, that’s why Build-Depends packages are for, don’t you think?
It seems it is not so simple. I could not understand why it was more important to prevent Debian users who need these files to access these files in a convenient way than letting them to put theses files in there own source tarball/repository. The maintainer told me it could break things. Sure. But we all know an external module of any app often relies on a really specific version of this app. That’s nothing new, thats how external modules work. That’s not every apps in the world which could provide a stable API to ease the development of external modules. But at least they give access to their dev files or headers when they are FOSS. But feel free to explain to me. After all, the bug reports are still not tagged as « won’t fix » 😉
Your turn now 🙂 I’d be delighted to have your opinions in the comments of this blog post.