Student Application Template
* Title: Automated Multi-Arch cross-building and bootstrapping
* Student: Gustavo Prado Alkmim
* Mentor: Wookey
* About me
I graduated in Computer Science at the Federal University of Lavras (Ufla/Brazil) in which I worked with virtualization using Xen. I was a member of Tecnolovre, a cooperative specialized on open-source based solutions. (http://www.tecnolivre.com.br) (They also have a very incomplete English page: http://www.tecnolivre.com.br/?p[l]=en). Currently, I am a master student at State University of Campinas (Unicamp/Brazil), working with Future Internet. My interest areas are network, security and general Linux management.
I used Linux since the very early of my graduation. I am one of the administrators of the LRC (Network Computer Laboratory) at Computer Institute, also in Unicamp, in which we use just Debian Linux systems. I have advanced skills on C++ and shell script and basic skills on Python and Java. If necessary, I have no problems in start on another programming language like Perl.
* Proposal Abstract
Currently people tend to use non-debian tools (such as Yocto/gentoo/OpenEmbedded) to get a basic rootfs image of the target arch/ABI then do native building within that. This works but needs a great deal of manual loop-breaking and it is important to debian to be able to bootstrap its own OS. Putting the necessary bootstrapping metadata and build rules into the packages themselves in an orderly fashion enables the info to be maintained easily. %QA (Quality Assurence) tests to report on breakage will help enormously. %It also makes for a repeatable and deterministic process.
Bootstrapping is closely related to support for cross-building Debian packages because at least part of the process must be done cross. Enough packages to make a bootable image need to be cross-buildable, because you cannot magic a system out of thin air. To move from cross to native building you need build-essential to be cross-buildable too.
The main goal of the project is to enable the easy and automated setup of a cross-platform automated build system for the QA (Quality Assurence) of the Multi-Arch era, and bootstrapping. This is a big problem and it involves two interesting areas:
1) Untangling circular build dependencies in Debian, and making a tool to sequence bootstrap builds. When the untangling work has been done it means that it would be possible to cross-build debian packages from scratch. However the sequencing of those builds needs a tool which understands about this bootstrap mode and can understand that some packages have more than one build-stage, with different dependencies. Doing those 'staged/bootstrap' builds allows progress and after a few more builds the 'full' version of the package can be built.
2) Making multiarch cross-building work, and making an automated cross-builder.
As explained before, this is a very big problem to be conclude inside the GSoC period. So, I'm going to concentrate on circular dependencies breaking and making a tool to sequence bootstrap builds. If time permits (probably not), I will start to make multiarch cross-building work and the automated cross-builder.
Some important steps that probably are going to be done:
1 - Study all the stuff related with the multi-arch support, cross-build and automated bootstrapping that is already documented. I'm going to understand in deep how Multi-arch support is currently solving the cross-building and bootstrapping processes. In this step is also included to get familiar with the tools currently used to make cross-building.
2 - Solve the circular dependencies that needs breaking (by adding info to each package to make them build more minimal versions with fewer dependencies). In "http://wiki.debian.org/DebianBootstrap" is estimated less than 50 packages will need significant work for dependency-cycle breaking. Many more than that need cross-building work.
3 - Making a tool to sequence bootstrap builds
4 - (If time permits) Make multiarch cross-building work and the automated cross-builder.
All the ideas shown here are just 'first look' ideas and possibly, while I get deep on the code, better approachs or unknowed problems may appear.