mock and package building

April 17, 2008

Recently I’ve been working on getting mock installed and configured on our new build server. The idea is to provide a set of chroots which authorized users can use for package building in an automated fashion. There are big advantages to doing things this way, for a start it only requires one machine to allow building for any RPM based platform (either i386 or x86_64 as long as the machine is installed as x86_64). It also requires packagers to be much more aware of their build requirements as the chroot is pretty minimal so unless the dependencies are well-specified the package won’t build. This should result in a much better quality of packaging which can be more easily distributed to other users and sites.

For reference, most of the information I needed to get mock correctly configured was taken from the fedora MockTricks wiki page. The most crucial bit I missed on the first pass was that on x86_64 you need to be careful with the yum configuration to exclude pretty much all i386 packages. If you don’t do that you get a chroot full of i386 packages which can cause interest problems, in particular file conflicts, when it comes to building some packages.

For each platform we are going to provide a set of chroots which have access to different package repositories. Taking sl5 as an example there is a basic chroot (named sl5-i386) which can access {distro,updates,extras,lcfg,world} buckets, there is a uoe chroot (uoe-sl5-i386) which has all of those buckets and can also access the uoe package repository and thirdly there is an inf chroot (inf-sl5-i386) which adds the inf bucket as well as uoe. The hope is that most packagers will use the basic chroot to minimize dependencies on locally built packages. Anything built in those chroots will have to go into the associated bucket, the packages should never be submitted to the lcfg or world bucket, for instance.

During testing of the chroots Simon and I discovered one unfortunate problem with the LCFG component source packages. The intention has always been that by bundling the various buildtools makefiles (e.g. os.mk, buildtools.mk, lcfg.mk) that the package could be rebuilt entirely independently of buildtools. This is not the case, without already having the lcfg-buildtools RPM installed it is impossible to rebuild an LCFG component SRPM. The only way this can be fixed is as part of the buildtools rewrite project.