Re: History of Debian bootstrapping/porting efforts
I read your recent post to debian-devel with great interest, as I've
done some bootstrapping efforts in the past, and I'm currently in the
middle of a "port" for the x32 ABI. In the past, what I've done
(mostly privately) was to develop a script I called "pbuildd" which
essentially just runs through the list of currently unbuilt packages
and tries running pbuilder on them all, then installs anything that
succeeds into a local repository and starts up the loop again. Then,
when things got stuck, I just did a manual inspection of the
unsatisfied dependencies to find the cycles, and chose one to break.
In fact, I've just started uploading my current iteration of this to
http://87.98.215.228/debian/ -- you might want to especially look at
scripts/pbuildd which is the central script to run this loop. (And
over time, it's gathered various optimizations to speed up the
"installation into local repository" step, try to avoid invoking
pbuilder if it can easily determine that certain Build-Depends aren't
present at all, etc.)
Initially, when I needed to break a cycle, I would just build
something by hand and stick it into the "partial" directory, but over
time I started developing automated cycle-breaker scripts, which are
currently under scripts/cb.inactive (the pbuildd script looks for them
under scripts/cb). The scripts tend to become outdated over time,
though, with a moving target, and I'm sure the current state is no
exception. My personal heuristics for what I preferred were: first,
prefer cycle-breaking which just removes Build-Depends which are there
to build documentation. Then, prefer cycle-breaking which ignores
Build-Depends on one or a few libraries which provide purely optional
features. If I couldn't find anything of this sort, I'd just try to
find the cycle-breaking point which would be (fuzzily) "least
invasive" and "least likely to break the resulting packages, at least
as far as packages that Build-Depend on them".
In the past, pbuildd was mainly geared towards trying to build all of
Debian (including the binary-indep packages) starting from a minimal
chroot and with minimal extra package downloads, but on an established
architecture. It was only recently that I started applying it to
bootstrapping x32. The way I started that was actually: I started off
mainly following the instructions from Linux From Scratch, though of
course adjusting it to "cross-building" to x32 as necessary. I also
inserted dpkg into the process as soon as possible after the first LFS
stage creating the chroot with /tools, and from then on ran installs
into temporary directories, and built dummy dpkg packages with no
dependencies. Then, after the LFS builds were over, I started
building real Debian packages from the actual .dsc source packages,
and eventually had enough packages built in this way that I was able
to do a debootstrap, and start the pbuildd process. (So yes, x32
might be a special case in that it runs on already widely available
hardware, and I could develop from an existing Debian installation.
But I'd imagine that was probably the case as well, though possibly to
a smaller degree, for the amd64 and ia64 ports, and possibly other
recent ports to new ABIs on existing hardware (armhf?).)
As for specifics on the x32 port -- currently the most common issues I
see (roughly from most common to least common) are:
* Outdated libtool, which causes it to want to ld -r with the wrong -m
target type. (And also ld -r more often than usual, because "getconf
ARG_MAX" outputs "undefined" on x32 in certain circumstances, which
the outdated libtool can't handle properly.) Of course this isn't an
issue for packages that autoreconf at build time.
* Issues which will hit every architecture once we switch to eglibc
2.16. Out of this, by far the most common is gnulib (other than very
recent git versions) wanting to attach a warning to the "gets"
prototype, which is no longer exported by default in eglibc 2.16.
* Code still using sysctl(2), which is no longer supported in x32.
* Code which unconditionally uses 64-bit asm snippets if __x86_64__ or
__amd64__ is defined -- which causes assembler failures if one of the
inputs or outputs is a long or a pointer type, and the asm snippet
uses explicit "q" sizing suffixes (or there are other mismatches).
--
Daniel Schepler
Reply to: