Hi this is another blog about my learnings with packaging in Debian, particularly autoreconf, libraries & lintian errors.
So, this started out with the idea of doing a Team upload of Geographiclib to fix a Fail To Build From Source (FTBFS) on the arm64 architecture. The idea was to pre-empt a bug becoming Release Critical (RC) in the future because ARM64 was probably about to become an official release architecture for Debian. There was a patch attached to the bug from Ubuntu (enabling autoreconf) which worked, so I proceeded to do the minimum of updates to the package and asked for sponsorship.
Unfortunately, I somehow missed that there was an “E” lintian error which would have resulted in an auto-rejection if it was uploaded. Basically, lintian is a system of checking Debian Packages for common errors, and non-compliance with Debian Policy. Here is the current lintian report for Geographiclib. Lintian lists for each package: Errors (E), Warnings (W), Information (I), Pedantic (P) tags. These can also be Overridden (O) if it is a “false positive”. I try to always have no E’s or W’s, but sometimes fixing these can result in more work than the general rule of “minimal changes” for Team Uploads.
So Andreas Tille (my regular sponsor in the Debian GIS team) gently encouraged me to become an uploader for the package, to update to the latest upstream version, and improve the packaging. So this started some learning! Firstly, Geographiclib comes with a shared library (for other programs to use), and this library had changed version. This is called a SONAME change (read about it here). This is reflected in the package name changing in Debian. For Geographiclib it changed from libgeographic10 to libgeographic13. Even though there are no reverse dependencies for Geographiclib (ie. no other package using the shared library), I decided to create a symbols file for it, and to begin managing the shared symbol version from now on into the future.
This seemed to go okay, but I was unable to build the package. However, if I reverted the autoreconf change it built fine. When failing, configure was spitting out various errors. Googling these found some information, but nothing that I could turn in to a solution. The Debian Autoreconf Wiki did not shed any light either. So once again I turned to the gurus that lurk on the Debian Mentors mailing list, and Jakub Wilk quickly identified that I was missing a dependency on autoreconf-archive.
So this enabled me to test the installation and then get it uploaded to Debian unstable. This turned out to be my next mistake. The package built fine on 64bit architectures, but failed on 32 bit ones. So – I ended up with a Release Critical Bug anyway! It turns out that the symbols are slightly different on 32 bit architectures, and I had to check all the failed build logs of the release architectures, and then place exceptions against each new or missing symbol. Even now, after fixing this, I discover that I should have checked the non-release architectures (ports), because some of these also have the same problem. So when it comes to libraries I have learnt this:
- Always release to experimental first. Then you can check that everything builds here before moving to unstable.
- Also keep an eye on the buildlogs after you release to unstable.
- Remember to check if the unofficial ports are okay.
Ross Gammon's Blog 