About Archive Tags RSS Feed

 

An experiment in (re)building Debian

20 November 2014 21:50

I've rebuilt many Debian packages over the years, largely to fix bugs which affected me, or to add features which didn't make the cut in various releases. For example I made a package of fabric available for Wheezy, since it wasn't in the release. (Happily in that case a wheezy-backport became available. Similar cases involved repackaging gtk-gnutella when the protocol changed and the official package in the lenny release no longer worked.)

I generally release a lot of my own software as Debian packages, although I'll admit I've started switching to publishing Perl-based projects on CPAN instead - from which they can be debianized via dh-make-perl.

One thing I've not done for many years is a mass-rebuild of Debian packages. I did that once upon a time when I was trying to push for the stack-smashing-protection inclusion all the way back in 2006.

Having had a few interesting emails this past week I decided to do the job for real. I picked a random server of mine, rsync.io, which stores backups, and decided to rebuild it using "my own" packages.

The host has about 300 packages installed upon it:

root@rsync ~ # dpkg --list | grep ^ii | wc -l
294

I got the source to every package, patched the changelog to bump the version, and rebuild every package from source. That took about three hours.

Every package has a "skx1" suffix now, and all the build-dependencies were also determined by magic and rebuilt:

root@rsync ~ # dpkg --list | grep ^ii | awk '{ print $2 " " $3}'| head -n 4
acpi 1.6-1skx1
acpi-support-base 0.140-5+deb7u3skx1
acpid 1:2.0.16-1+deb7u1skx1
adduser 3.113+nmu3skx1

The process was pretty quick once I started getting more and more of the packages built. The only shortcut was not explicitly updating the dependencies to rely upon my updages. For example bash has a Debian control file that contains:

Depends: base-files (>= 2.1.12), debianutils (>= 2.15)

That should have been updated to say:

Depends: base-files (>= 2.1.12skx1), debianutils (>= 2.15skx1)

However I didn't do that, because I suspect if I did want to do this decently, and I wanted to share the source-trees, and the generated packages, the way to go would not be messing about with Debian versions instead I'd create a new Debian release "alpha-apple", "beta-bananna", "crunchy-carrot", "dying-dragonfruit", "easy-elderberry", or similar.

In conclusion: Importing Debian packages into git, much like Ubuntu did with bzr, is a fun project, and it doesn't take much to mass-rebuild if you're not making huge changes. Whether it is worth doing is an entirely different question of course.

Tags: debian, misc | 2 comments

 

Comments on this entry

icon ESL at 14:57 on 21 November 2014

Hi! Do you have the script you used to rebuild published somewhere? Thabk you!

icon Steve Kemp at 15:03 on 21 November 2014

There was no script. What I did was install a minimal system, then for each package install the build-dependencies. This gave me a complete system with all packages required to rebuild itself.

i.e Install the system, then install all build-deps :

# for i in $(dpkg --list | grep ^ii | awk '{print $2}'); do apt-get build-dep $i ; done

Repeat until each of the build-dependencies has its own build dependencies present. Then for each package get the source:

apt-get source $foo

Change to the directory, add the new version suffix, and create a new source package:

export DEBFULLNAME="Steve Kemp"
export EMAIL="steve@steve.org.uk"
dch  --local skx "Rebuilt with my suffix."
debuild -S -sd

The end result of that should be that you have a hell of a lot of source packages, each of which contains zero changes except for an "skx" suffix in the package version.

From there you rebuild each package, one by one, via pbuilder. This gives you all the binaries which you can then import into a local repository - which you then configure your pbuilder instance to install from, allowing you to rebuild a second time.

 

Created by ephemeris.

© Steve Kemp