Johannes Schauer dixit:
>If you were ever involved in porting Debian to a new architecture or
>know how a port was done, please do not hesitate to either write me an
For reviving m68k:
> - did you cross compile parts of Debian? How much? How hard was it?
Only to test kernels and a few userspace issues. I was lucky I could
use packages from both etch-m68k (a snapshot of mostly sid at the time
when etch was released) and unstable (mostly broken by then) as basis.
> - did you natively compile on another distribution (openembedded,
> gentoo)
No, just on old Debian, peu à peu, until I could get cowbuilder
running and create a clean build chroot, after which I rebuilt
all not-cleanly-built packages. (I prefer cowbuilder over sbuild
a lot!)
> - how did you go about finding reduced build dependencies? What were
> the heuristics you used? How did you find dependency cycles to break
> and how did you pick a solution?
Fully manually. I mostly drew ASCII files like this:
sourcepkg1
sourcepkg2
sourcepkg3
sourcepkg4
sourcepkg5
sourcepkg3<dup>
sourcepkg6
sourcepkg2<cyc>
The web view on packages.debian.org was, and still is, a *huge*
help for drawing those, especially as it also includes packages
from debian-ports unstable in their sid view (I just wish they’d
also include d-p unreleased suite in it, even without a link but
just an inclusion in the version table would be superb).
Then I worked on them from right to left, occasionally patching
a huge dependency out or breaking a B-D loop by hand, sometimes
also installing older versions of B-Ds manually, or even building
versions older than sid but newer than what I had.
Sometimes, package maintainers were a huge help in tracking down
optional dependencies or things I could turn off for bootstrapping;
too bad we still don’t have build profiles in Debian proper.
Other times, I did that using human judgment ;)
> - how long did the port take you?
After about a year, doing this “on the side”, i.e. not concentrating
on it a lot, and considering the very slow speed of the systems, most
things were working. One has to consider I learned about how Debian
really works during that time, too…
> - what were the most common bugs you filed when introducing the new
> architecture?
Dropping of B-D or versioning them proper or making them arch-specific.
For some packages (mostly toolchain, some device drivers like libdri)
also patch inclusion.
Almost all maintainers and the kernel team were very helpful and
happy to include arch-specific patches that did not touch MI parts,
and some accepted MI patches as well. For some, I went upstream,
which took months(!) longer in most cases.
> Build-Depends: huge (>= 1.0) [i386 arm] <!embedded !bootstrap>, tiny
Yeah, waiting for it…
As for the rest, we already talked on the mailing list.
bye,
//mirabilos
--
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font. -- Rob Pike in "Notes on Programming in C"
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/pine.bsm.4.64l.1211202112490.29...@herc.mirbsd.org
