Backporting packages

• The expression sounds like a trivial activity
• In many cases, it is
• The general case it's not (at all)
• It's like recompiling a Qt4 app having only Qt3
• The software could need newer versions of other software
• The packaging could need newer tools

Example

• WARNING: You should know how to package software!
• Let's try to recompile some Ubuntu package in Debian Etch
• In particular, the package file
• Seems simple. But don't let that fool you ;-P
• This package has some common/interesting problems
• Many others are trivial to backport

First step: recompile and watch

• Get the source package (that's three files!)
• Extract with dpkg-source -x blahblah.dsc
• Enter the directory, type debuild -us -uc (no GPG)
• First problem :-(

  dpkg-checkbuilddeps: Unmet build dependencies: debhelper (>= 7) python-all-dbg
  dpkg-buildpackage: Build dependencies/conflicts unsatisfied; aborting.
    

• debhelper is only version 5
• python-all-dbg is not available at all

Second step: tweak dependencies

• We'll have to either compile those dependencies, or remove them
• Probably we don't really really need a modern debhelper
• Probably we can do without Python debugging packages
• So, let's hack debian/control to remove the dependencies
• Let's add an entry in debian/changelog (with dch) to note we are butchering the package
• Let's try again. Another problem:

  dh_clean: Sorry, but 5 is the highest compatibility level supported by this debhelper.
    

• Ah, of course. That's debian/compat saying that it needs debhelper 7

Third step: removing features

• After fixing debian/compat, we try again:

    /bin/sh: line 2: python2.4-dbg: command not found
    /bin/sh: line 2: python2.5-dbg: command not found
    

• Well, the package did depend on python-all-dbg
• We decided we didn't need it, so let's remove those "features"
• Hack debian/rules to remove/change references to python-dbg
• Don't forget to remove python-magic-dbg from debian/control

Fourth step: unexpected silly problems

• Recompiling again gives:

    reverting patch 904-file-make from ./ ... failed.
    

• I have no idea why this happens (package bug?)
• But it's easy to fix (just patch by hand so it can revert)
• Another problem with lt_main.sh:

  dpkg-source: cannot represent change to ltmain.sh:
  dpkg-source:  new version is symlink
  dpkg-source:  old version is something else
  dpkg-source: building file in file_4.24-4.dsc
  dpkg-source: unrepresentable changes to source
    

• That's some autohell^W^W^W^Wtools problem, just rm
• To remove some cruft, fakeroot debian/rules clean is useful

Fifth step: non-existent tools

• Are we there yet?

  dh_lintian
  make: dh_lintian: Command not found
  make: *** [binary-arch] Error 127
  debuild: fatal error at line 1228:
    

• No :-(
• dh_lintian, WTF?
• lintian is a tool to perform quality "metrics" on the package (like lint)
• We don't have dh_lintian available (debhelper 7)
• We can just remove the call
• If we recompile again, we have a winner! \o/

Other advice: renaming packages

• Sometimes useful, to make clear that it's a modified version (e.g. adding -ldap or -patched)
• Not hard, but some gotchas
• debian/control: change binary package name.
• debian/rules: install the files under the correct directory.
• debian/packagename.*: let debhelper do its stuff in the new package.

Other advice: virtual packages

• When we rename, we want to keep fulfilling dependencies
• We can say that a package Provides: another one
• Just add the entry in debian/control, but use with care
• Versioned dependencies (Depends: foo (>= 3)) don't work!
• Actually the feature was invented for things like www-browser and such.

Takk!

Picture credits

• Andrew Cosand
• Dan4th Nicholas
• Paul Walker